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ABSTRACT 


In  support  of  the  Naval  Research  Laboratory  and  Naval  Sea  Systems 
Command  during  the  period  25  August  1980  through  30  October  1981,  ARINC 
Research  Corporation  provided  technical  services  to  the  Navy  by  serving  as 
a  member  of  the  Data  Bus  Specification  Working  Group  (DBSWG)  chartered  to 
develop  a  specification  for  the  data- transfer  network.  This  report  describes 
the  results  of  tasks  undertaken  by  the  DBSWG  during  this  period. 
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FOREWORD 


This  final  report  summarizes  the  activities  of  ARINC  Research 
Corporation  in  support  of  the  Naval  Research  Laboratory  and  Naval  Sea  Sys¬ 
tems  Command  for  the  period  25  August  1980  to  30  October  1981.  The  work 
was  performed  under  Contract  N00173-79-C-0463  to  the  Naval  Research 
Laboratory.  The  report  reflects  the  work  of  the  entire  Data  Bus  Speci¬ 
fication  Working  Group  { DBSWG) .  ARINC  Research  wishes  to  acknowledge  the 
contributions  made  by  the  other  organizations  represented  on  the  DBSWG: 
Naval  Surface  weapon  Center,  Dahlgren;  Naval  Underwater  Systems  Center, 

New  London;  Naval  Ocean  Systems  Center;  and  John  Hopkins  University, 
Applied  Physics  Laboratory. 
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CHAPTER  ONE 


INTRODUCTION 


1.1  BACKGROUND 

Increasing  emphasis  is  being  placed  on  reducing  the  costs  and  improv¬ 
ing  the  effectiveness  of  military  electronic  equipment.  Constraints  on 
military  budgets ,  coupled  with  inflation  and  rising  operating  and  support 
costs,  are  prompting  a  search  for  methods  of  reducing  the  cost  of  acquiring 
equipment  and  maintaining  it  throughout  its  life  cycle. 

Alternative  techniques  for  the  acquisition,  maintenance,  and  support 
of  equipment  are  available.  One  alternative  is  the  application  of  com¬ 
mercial  practices  and  equipment.  The  Department  of  Defense  (DoD)  has 
recently  directed  attention  to  the  procurement  technique  of  the  U.S.  com¬ 
mercial  airline  industry.  Known  as  the  Commercial  Airline  Acquisition 
Methodology  (CAAM) ,  this  approach  concentrates  on  technology  and  develop¬ 
ment  planning  for  the  procurement  of  aircraft  avionics.  Techniques  of  this 
type  are  of  interest  because  they  are  relatively  simple  in  comparison  with 
military  processes.  They  are  also  efficient  in  acquiring  state-of-the-art 
electronic  systems  that  offer  excellent  cost  and  reliability  advantages. 

The  new  Guided  Missile  Destroyer  (DDGX)  combat  system  is  one  program 
in  which  application  of  the  CAAM  is  considered  feasible  and  beneficial. 

This  Navy  program  is  developing  a  data  bus  form,  fit,  and  function  specifi¬ 
cation,  including  interface  and  protocols,  for  use  in  the  DDGX  combat  sys¬ 
tem.  There  has  been  much  discussion  on  the  use  of  data  buses  in  surface 
ship  combat  systems.  The  Navy  is  pursuing  a  project  for  a  ship-signals 
data  bus  but  is  not  yet  developing  a  combat  system  data  bus  for  digital 
computers  and  peripherals. 

The  combat  systems  of  modern  surface  ships  contain  networks  of  computers 
that  distribute  data  to  various  combat  system  elements.  In  the  CGN-38  and 
CG-47  Classes,  the  computers  are  generally  concentrated  in  one  location  for 
ease  of  maintenance  and  operation.  The  computer  networks  are  "ad  hoc": 
they  join  independently  designed  and  implemented  subsystems  by  using  avail¬ 
able  tools  and  components,  both  hardware  and  software,  and  in  some  instances 
by  using  specially  designed  components  (e.g.,  data  buses,  conversion  sets, 
and  switches) .  Data  transmission  is  generally  implemented  over  point-to- 
point  wiring.  A  significant  part  of  the  data  transmission  network  is  used 
for  transmitting  low-data-rate  status  and  control  signals  between  computers 
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and  controlled  devices  (launchers  and  radars,  for  example).  Because  the 
designs  of  subsystems  and  combat  systems  predate  the  current  commercial 
and  academic  interest  in  distributive  processing,  they  do  not  reflect  all 
currently  available  technology. 

The  combat  systems  of  major  combatant  ships  are  very  complex.  For 
this  reason,  they  are  divided  into  elements  or  subsystems  (e.g. ,  guns, 
radars,  and  missiles)  to  facilitate  their  management  and  to  make  them 
usable  in  different  ship  classes.  This  functional  allocation  changes 
slowly  as  changing  requirements  and  technology  mandate.  For  example,  the 
Vertical  Launch  System  (VLS)  will  replace  a  number  of  separate  launchers 
used  as  part  of  anti-air,  anti-surface,  and  anti-submarine  weapon  systems. 
The  functional  allocation  and  staggered  development  time  makes  it  necessary 
to  integrate,  on  a  single  ship,  components  based  on  different  computer  tech¬ 
nologies.  It  also  leads  to  conflicting  goals  arising  from  the  requirement 
for  efficient  implementation  of  a  subsystem  and  efficient  integration  of  sub' 
systems  into  the  total  ship  combat  system.  While  recent  developments  in 
computer  network  design  may  alleviate  some  of  the  difficulties,  the  basic 
problem  will  not  be  eliminated . 

The  integration  problem  is  becoming  more  crucial  because  of  the  grow¬ 
ing  need  to  distribute  common  data  (e.g.,  navigation  data  or  track  informa¬ 
tion),  to  share  resources  (e.g.,  launchers  and  sensors)  among  a  variety  of 
competing  users,  and  to  perform  functions  (e.g.,  training,  test,  and 
maintenance)  that  cut  across  established  subsystem  boundaries. 

One  current  approach  to  alleviating  this  integration  problem  is  to 
standardize  certain  common  critical  components,  such  as  computers  (AN/UYK-7 
and  AN/UYK-20  currently  and  AN/UYK-43  and  AN/TJYK-44  in  the  future) ,  pro¬ 
gramming  languages  (CMS-2) ,  operating  systems  (SDEX-2C  and  SDEX-7) ,  and 
data  transmission  methods  (NTDS  fast  channels) .  The  details  of  the  way  in 
which  data  are  communicated  between  subsystems  and  within  subsystems  have 
historically  been  left  to  subsystem  designers.  The  existence  of  a  dis¬ 
tributed  network  of  computers  to  carry  out  a  given  task  implies  an  alloca¬ 
tion  of  functions  to  various  computers  and  other  devices  in  the  network. 

The  design  of  a  combat  system  for  a  ship  also  requires  an  allocation  of 
functions  to  various  elements.  Because  of  the  intrinsic  complexity  of  com¬ 
bat  systems  and  the  large  amount  of  existing  subsystem  design  that  must  be 
used  in  any  new  combat  system,  change  must  be  evolutionary. 

The  joining  of  a  combat  system's  computers  into  a  network  raises  a 
number  of  important  issues  that  must  be  resolved  in  establishing  an  archi¬ 
tectural  philosophy  for  the  data  bus.  Among  these  issues  are  system  syn¬ 
chronization,  establishment  of  interfaces  and  protocols,  efficient  fault 
tolerance,  secure  data  transmission,  sharing  of  common  resources,  parti¬ 
tioning  of  the  data  bus,  and  management  of  the  transfer  of  information  by 
the  data  bus. 

Industry  is  actively  pursuing  independent  research  and  development 
(IR&D)  programs  in  order  to  obtain  technical  understanding  of  bus  applica¬ 
tions  and  to  be  prepared  for  procurements  requiring  such  capability.  While 


many  of  the  claims  for  a  fully  sophisticated  combat  system  are  not  yet 
validated,  it  is  clear  that  some  major  applications  of  limited  scope  are 
practical  in  the  near  future  and  have  potentially  high  benefit. 

1.2  APPROACH 

The  NAVSEA  approach  to  developing  a  data  transfer  network  for  as 
a  tool  by  the  DDGX  combat  system  designers  was  to  form  a  Data  Bus  Specifica¬ 
tion  Working  Group  (DBSWG)  that  would  produce  the  architectural  description 
and  prepare  a  technical  specification  for  the  data  bus.  The  group  con¬ 
sisted  of  technical  personnel  from  Naval  Surface  Weapons  Center  (NSWC) , 

Naval  Ocean  Systems  Center  (NOSC) ,  Naval  Underwater  System  Center  (NUSC) , 
Johns  Hopkins  University /Applied  Physics  Laboratory  (JHU/APL) ,  and  ARINC 
Research  Corporation.  NSWC  and  JHU/APL  cochaired  the  group,  and  ARINC 
Research  was  the  Secretariat. 

The  objective  of  the  working  group  was  to  develop  an  architectural 
description  of  a  data-transf er  network  interface  that  could  be  used  in 
the  acquisition  of  subelements  for  the  DDGX  combat  system.  In  this  task 
detailed  deliberations  were  to  be  restricted  to  data  bus  equipment  inter¬ 
faces,  associated  protocols,  and  bus  performance  that  are  necessary  to  sup¬ 
port  the  DDGX  and  other  combat  system  applications.  The  experience  gained 
by  the  commercial  airlines  and  by  the  Naval  Air  Systems  Command  (NAVAIR) 
and  the  Air  Force  in  the  use  of  MIL-STD-1553B  was  to  be  studied  and  applied 
where  applicable. 

ARINC  Research  was  tasked  by  the  Naval  Research  Laboratory  (NRL) , 
under  Contract  N00173-79-C-0463,  to  participate  in  the  technical  activities 
of  the  DBSWG  and  serve  as  the  group’s  Secretariat.  Two  specific  tasks  of 
the  DBSWG  that  ARINC  Research  was  to  support  are  as  follows: 

•  Task  One:  Develop  architectural  philosophy  for  data-transf er  network 

•  Task  Two:  Obtain  industry  coordination 

In  Task  One,  the  DBSWG  planned  to  collect  engineering  data  concerning 
the  projected  DDGX  information  flow,  such  as  data  rate,  message  size  and 
frequency,  and  acceptable  delays.  Existing  protocol  and  interface  standards, 
such  as  the  International  Standardization  Organization  (ISO)  reference  model, 
and  various  industry  standards  would  be  evaluated  for  use  as  a  basis  for  a 
combat  system  communications  reference  model.  In  addition,  the  DBSWG 
planned  to  formulate  a  plan  to  attract  industry  interest,  obtain  industry 
comments  on  the  architectural  philosophy,  and  foster  a  competitive 
environment. 

This  report  summarizes  the  work  accomplished  under  the  contract  from 
25  August  1981  to  30  October  1981.  Since  ARINC  Research  Corporation  per¬ 
formed  as  part  of  the  DBSWG,  accomplishments  of  the  entire  working  group 
are  described,  with  emphasis  on  the  specific  role  of  ARINC  Research  as 
appropriate.  Chapter  Two  describes  the  results  of  the  tasks.  Chapter  Three 
presents  conclusions  and  recommendations  for  future  developments.  Appendixes 
A  through  H  present  specific  products  prepared  by  the  DBSWG. 


CHAPTER  TWO 


RESULTS 


This  chapter  summarizes  the  results  of  DBSWG  efforts  to  develop  an 
architectural  description  of  a  DDGX  data-transf er  network,  with  emphasis 
on  the  role  played  by  ARINC  Research  Corporation.  The  DBSWG  was  cochaired 
by  Mr.  D.  Green  of  NSWC  Dahlgren  and  Dr.  T.  Sleight  of  JHU/APL.  ARINC 
Research  Corporation  served  as  the  DBSWG  Secretariat. 


2.1  TASK  ONE:  DEVELOP  ARCHITECTURAL  PHILOSOPHY  FOR  DATA-TRANSFER 

NETWORK 

The  activities  of  the  DBSWG  began  with  the  first  formal  meeting  at 
ARINC  Research  Corporation  on  3  and  4  September  1980.  The  general  charter 
of  the  working  group  was  reviewed,  and  all  DBSWG  members  made  presentations 
providing  background  on  their  organizational  experience  with  data  buses. 
Splinter  groups  were  established  to  conduct  working  sessions  on  specific 
areas.  Appendix  A  is  a  report  of  this  meeting  describing  the  detailed 
discussions  that  took  place  and  the  working  groups  established.  The  meet¬ 
ing  was  significant  since  it  formally  established  the  working  group  and 
assigned  splinter  group  responsibilities.  In  addition,  general  agreement 
was  reached  by  the  attendees  that  a  layered  protocol  model,  similar  to  the 
International  Standards  Organization  (ISO)  Open  System  Interconnection 
(OSI)  reference  model,  should  be  the  basis  of  the  data-transfer  network 
specification.  Figure  2-1  depicts  the  OSI  reference  model. 

Following  the  initial  meeting,  much  of  the  work  of  the  DBSWG  was 
accomplished  in  subcommittee  meetings  or  informal  working  groups.  Activity 
was  centered  on  the  following  areas: 

•  Program  plan  development 

•  Air  Force  and  NAVAIR  MIL-STD-1553B  experience 

•  Foreign  experience 

•  Reference  model  development 

•  Evaluation  of  Standard  Information-Transfer  Architecture  for 
Combat  Systems  (SITACS) 
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Figure  2-1.  OPEN  SYSTEMS  INTERCONNECTION  REFERENCE  MODEL 


These  activities  are  discussed  in  the  following  subsections.  In  addition, 
the  efforts  to  obtain  industry  comments  are  discussed  in  Section  2.2. 

2.1.1  Program  Plan  Development 

ARINC  Research  participated  in  developing  a  program  plan  to  define 
a  program  for  the  development  of  an  inter-computer /peripheral  data-transfer 
mechanism  specification  for  information  transfer  between  combat  system 
components  by  means  of  a  shared  data  path,  such  as  a  data  bus.  The  speci¬ 
fication  will  be  applied  initially  to  the  next-generation  Guided  Missile 
Destroyer,  DDGX.  Development  of  the  plan  was  an  iterative  process,  with 
members  of  the  DBSWG  providing  comments  on  the  draft,  which  were  resolved 
and  incorporated  in  an  updated  plan  for  further  comment.  The  final  program 
plan  is  reproduced  in  Appendix  B. 

2.1.2  Air  Force  and  NAVAIR  MIL-STD-1553B  Experience 

The  Air  Force  and  NAVAIR  had  already  developed  a  standard  (MIL-STD- 
1553)  for  multiplexing,  and  the  DBSWG  was  interested  in  obtaining  an  under¬ 
standing  of  the  experience  acquired  in  that  development.  For  that  purpose, 
ARINC  Research  attended  the  Air  Force  Systems  Command  Multiplex  Data  Bus 
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Conference  on  17,  18,  and  19  November  1980.  The  Air  Force  had  documented 
much  of  its  experience  in  the  MIL-STD-1553  Multiplex  Applications  Handbook, 
which  was  provided  to  conference  attendees  and  distributed  by  ARINC  Research 
to  all  DBSWG  members.  A  short  discussion  of  the  need  to  develop  this  stan¬ 
dard  is  provided  in  the  following  paragraphs. 

The  need  to  increase  avionics  integration  was  first  realized  when 
requirements  for  missions  and  their  associated  avionic  hardware  could  no 
longer  be  met  practically  with  independent  and  self-sufficient  subsystems 
or  elements.  The  most  frequently  cited  reasons  for  integration  are  space 
limitations;  the  need  to  eliminate  unnecessary  duplication  of  information 
sensing  and  display;  and  the  desire  to  improve  performance,  increase  relia¬ 
bility,  and  reduce  costs.  Integration  usually  began  with  the  most  complex 
subsystems  because  they  had  the  most  capability,  as  well  as  the  greatest 
need  for  information  from  other  subsystems.  As  digital  technology  progressed, 
central  subsystems  were  expanded  to  incorporate  the  processing  of  mission- 
related,  as  opposed  to  subsystem-related,  functions. 

Problems  arose  early  in  the  centralization  effort  because  the  design 
of  subsystems  was  not  focused  on  interconnection  with  other  systems  but  on 
specialized  interfaces  where  necessary.  The  input-output  (I/O)  circuitry 
of  the  central  computer  was  designed  to  perform  the  function  of  ordering 
this  incoming  and  outgoing  data,  with  the  result  that  I/O  complexity  exceeded 
that  of  the  central  computer.  However,  the  concept  of  the  central  computer 
and  its  associated  integration  upgraded  the  capability  of  the  mission  and 
made  practical  the  use  of  shared  information.  The  solution  to  these  cen¬ 
tralization  problems  related  to  the  complexity  of  the  I/O  was  to  partition 
and  distribute  the  I/O  circuitry,  reducing  the  central  computer's  complexity. 
This  solution  was  supported  by  trends  in  commercial  data  transfer. 

Multiplexing,  which  makes  information  transfer  convenient  and  simpli¬ 
fies  I/O,  offered  the  partitioning  capability,  and  the  extended  computer  I/O 
philosophy  was  developed.  Multiplexing  makes  information  exchange  convenient 
because  sensors  and  processors  are  all  "on  the  bus."  Multiplexing  simplifies 
I/O  because  the  information-transfer  medium  is  reduced  to  a  single  wire  pair. 
This  extended  I/O  philosophy  was  adopted  extensively  by  military  avionics 
integrators  with  the  development  and  use  of  military  minicomputers  and  the 
availability  of  lower-cost  digital  components.  These  integrated  avionics 
systems,  which  came  to  be  referred  to  as  multicomputer  systems,  made  it 
possible  to  distribute  the  computation  and  to  replace  the  more  powerful 
central  processor  with  several  computers.  In  addition,  these  multiple  com¬ 
puters  added  desirable  redundancy  features.  MIL-STD-1553  and  the  Digital 
Avionic  Information  System  (DAIS)  were  developed  according  to  this  integra¬ 
tion  concept. 

This  concept  is  applied  in  various  forms  today  on  several  aircraft 
(e.g.,  B-l,  F-16,  F-18,  and  the  Space  Shuttle).  From  the  subsystem  equip¬ 
ment  point  of  view,  these  approaches  to  integration  use  both  integration 
units  for  unmodified  subsystem  interfaces  (interface  boxes  that  1553 
refers  to  as  remote  terminals)  and  embedded  interfaces  (1553  interface 
circuitry  housed  within  a  subsystem  box) .  These  remote  terminals  (RT)  or 


embedded  1553  interfaces  connect  the  subsystems  to  the  data  buses.  The 
current  trend  of  embedding  the  interface  in  the  subsystem  is  expected  to 
continue. 

2.1.3  Foreign  Experience 

A  two-day  meeting  of  representatives  of  the  German,  Canadian,  and  D.S. 
Navies  was  held  on  3  and  4  March  1981  to  address  a  common  definition  and 
description  of  a  distributed  architecture.  Members  of  the  DBSWG  were  in 
attendance  on  both  days.  The  following  topics  were  presented  and  discussed: 

•  DDGX  Design  Considerations  -  R.  Hill 

•  Distributed  Processing  -  T.  Sleight/D.  Green 

•  Shipboard  Distributed  Multiplex  System  (SDMS)  -  M.  Wapner 

•  Advanced  Sensor  Integration  Tactical  Data  Processing  (ASI/TDP)  - 
P .  Andrews 

•  Low-Level  Serial  -  R.  Kolb 

•  Standard  Information  Transfer  Architecture  for  Combat  Systems 
(SITACE)  -  R.  Fastring 

•  Shipboard  Integrated  Processing  and  Display  System  (SHINPADS)  - 
CDR.  J.  Carruthers  (CN) 

•  Fiber  Optic  Communication  Network  (FOCON)  -  German  team 

Appendix  C  presents  the  minutes  of  the  meeting.  It  provides  details  of 
the  discussions  held  and  results  of  the  work  group  sessions  held  on  the 
second  day.  No  new  positions  were  developed,  but  arrangements  for  future 
data  exchange  were  made. 

2.1.4  Reference  Model  Development 

A  reference  model  for  data-transfer  systems  to  be  used  in  Navy  surface 
combat  systems  was  developed  by  the  Reference  Model  Subcommittee  of  the 
DBSWG.  The  model  focused  on  projected  Navy  combat  system  requirements, 
particularly  DDGX  requirements,  and  was  to  serve  as  the  following: 

•  A  foundation  from  which  data-transfer  systems  could  be  specified 

•  An  organizing  construct  in  describing  data-transfer  mechanisms 

•  A  basis  for  comparison  of  existing  and  future  systems 

Appendix  D  reproduces  the  draft  of  the  reference  model  developed  by 
the  subcommittee,  which  was  designated  as  Modelman.  The  basic  model 
consists  of  five  layers,  which  are  defined  in  Appendix  D.  The  intent  of 
the  DBSWG  is  that  these  definitions  constitute  a  set  of  mandatory  require¬ 
ments  that  candidate  data-transfer  systems  must  meet.  In  developing 
candidate  approaches  in  the  future,  it  is  anticipated  that  developers 
will  define  characteristic  features  and  functions  of  each  layer.  In  this 
way  a  communications  framework  will  be  formed  that  will  establish  the  nature 
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of  a  particular  system's  layers  and  serve  as  a  foundation  for  further  devel¬ 
opment  of  each  candidate  system.  Appendix  E  describes  representative  func¬ 
tions  by  layer,  and  Appendix  F  presents  hardware  implementation  examples  for 
the  Modelman  reference  model. 

2.1.5  SITACS  Evaluation 


The  DBSWG  evaluated  a  plan  by  SEA-61  to  develop  a  standard  information- 
transfer  system  architecture  plan  that  would  (1)  guide  the  specification  and 
design  of  an  overall  interconnection  architecture ,  (2)  define  the  physical/ 
electrical  interface  and  communications  protocols  needed  for  subsystem 
acquisition  planning,  and  (3)  produce  a  CFE/GFE  development  specification 
to  support  the  procurement  of  subsystems  with  embedded  terminals  or  stand¬ 
alone  terminals  to  be  used  by  equipments  that  have  standard  Low-Level  Serial 
(LLS)  interfaces. 

Comments  were  provided  by  DBSWG  members  and  consolidated  by  ARINC 
Research.  The  consensus  of  the  DBSWG  was  that  the  SITACS  approach,  while 
feasible,  was  only  one  specific  implementation  scheme  that  could  satisfy 
DDGX  data-transfer  requirements.  As  such,  it  was  recommended  that  SITACS 
be  included  as  one  of  the  alternative  technical  approaches  (strawmen)  dis¬ 
cussed  in  Appendix  B.  Additional,  detailed  comments  are  provided  in 
Appendix  G. 


2.2  TASK  TWO:  OBTAIN  INDUSTRY  COORDINATION 

A  key  requirement  in  the  development  of  a  data-transfer  network  speci¬ 
fication  was  to  obtain  industry  review  and  comment  on  strawman  specifications 
and,  subsequently,  on  draft  and  final  specifications.  In  preparation  for 
the  development  of  strawmen,  the  Navy  desired  to  perform  a  number  of  produc- 
ibility  studies  by  industry  data  bus  designers  and  manufacturers.  Studies 
to  be  performed  included,  but  were  not  necessarily  limited  to,  the  following: 

•  Conduct  parametric  analysis  of  the  cost  of  building  and  maintaining 
serial  receiver/transmitter  interfaces 

•  Prepare  engineering  estimates  of  the  cost  to  design,  build,  test, 
and  maintain  data  bus  terminals 

•  Perform  parametric  analysis,  using  a  suitable  model,  of  the  impact 
of  different  bus  access  techniques  on  bus  access  time  and  message 
queue  size 

•  Review  and  analyze  data  bus  specifications  for  producibility, 
completeness,  operational  suitability,  survivability,  extensibility, 
and  flexibility 

•  Utilize  the  data  bus  specifications  and  a  description  of  the  DDGX 
combat  system  to  show  how  a  distributed  version  of  the  DDGX  could 
be  designed 
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•  Develop  estimated  costs  of  generating  any  required  operating 
system  software,  error  detection,  and  correction  systems,  and 
support  hardware  or  software  required  for  DDGX 

•  Determine  a  suitable  formal  specification  language  and  use  it  to 
encode  one  version  of  the  specification 

A  synopsis  of  the  proposed  procurement  appeared  in  the  Commerce 
Business  Daily  on  11  December  1980.  A  number  of  responses  were  received 
from  industry  as  a  result  of  the  announcement.  Firms  submitting  letters 
of  interest  in  performing  data  busing  producibility  studies  are  listed  in 
Appendix  H. 


CHAPTER  THREE 


CONCLUSIONS  AND  RECOMMENDATIONS 


3 . 1  CONCLUSIONS 

In  conducting  investigations  of  data-transfer  requirements  for  the 
DDGX,  the  DBSWG  reached  a  number  of  conclusions  regarding  the  application 
of  data-transfer  networks  for  DDGX  and  future  ships.  Since  the  DBSWG  is 
a  committee  formed  of  members  who  do  not  necessarily  share  identical  views, 
a  specific  set  of  conclusions  was  not  achieved.  However,  the  analyses  con¬ 
ducted  by  the  DBSWG  resulted  in  the  following  general  observations : 

•  Data  busing  has  already  begun  in  Navy  combat  systems  at  the 
element  level  as  program  managers  procure  subsystems  with  data 
buses  embedded  in  the  design. 

•  The  results  of  this  trend  toward  data  busing  could  result  in  a 
proliferation  of  nonstandard  proprietary  data  buses  as  part  of 
future  combat  systems. 

•  A  layered  communications  model  similar  to  the  ISO  model  should 
be  developed  for  Navy  combat  systems  inter-computer/peripheral 
communications . 

•  Efforts  to  apply  a  data-transfer  network  to  the  DDGX  should 
continue . 

•  Planning  for  data-transfer  networks  for  future  ship  classes  should 
begin  now  so  that  the  scheduling  problems  that  so  frequently  occur 
can  be  avoided. 

On  the  basis  of  more  than  a  year's  participation  in  DBSWG  efforts, 
ARINC  Research  Corporation  believes  that  the  issues  associated  with  data- 
transfer  networks  for  Navy  combat  systems  have  serious  implications  for 
both  DDGX  and  future  ship  design.  In  particular,  the  growth  of  data  buses 
at  the  subsystem  and  element  levels  threatens  to  cause  a  broad  prolifera¬ 
tion  of  nonstandard  and  proprietary  data-transfer  networks  for  Navy  combat 
systems,  with  each  network  having  its  own  architecture,  interfaces,  and 
logistics  requirements.  This  could  result  in  the  need  to  develop  specific 
interface  equipment  to  achieve  communication  between  data  transfer  networks. 
In  addition,  severe  logistics  problems  could  arise  because  of  the  need  to 
support  all  of  the  data-transfer  networks  in  the  Fleet. 
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3.2  ARINC  RESEARCH  CORPORATION  RECOMMENDATIONS 


ARINC  Research  recommends  that  the  development  of  data-transfer  network 
specifications  be  pursued  for  both  DDGX  Class  ships  and  the  SSES  program. 

The  SSES  program  is  currently  being  pursued  by  NAVSEA  to  achieve  physical 
and  functional  separation  of  the  platform,  hull,  and  payload  elements  through 
the  development  of  engineering  standards  that  allow  the  design  and  construc¬ 
tion  of  the  platform  to  take  place  independently  of  the  combat  system  ele¬ 
ments.  Appendix  B  is  a  program  plan  for  developing  the  specifications  for 
both  programs,  particularly  the  DDGX.  In  addition,  under  a  separate  con¬ 
tract  to  NAVSEA,  ARINC  Research  and  NUSC  have  begun  to  prepare  a  plan  for 
developing  SSES  engineering  standards  for  data-transfer  networks.  ARINC 
Research  recommends  that  data-transfer  network  engineering  standards  be 
developed  for  SSES  ships  to  support  the  SSES  program  objective  of  decoupling 
the  payload  (system)  from  the  platform  (ship) . 
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APPENDIX  A 


MEETING  REPORT: 

DATA  BUS  SPECIFICATION  WORKING  GROUP 
3-4  September  1980 

This  appendix  reproduces  the  report  of  the  first  meeting  of  the  Data 
Bus  Specification  Working  Group.  Because  of  their  volume,  enclosures  (2) 
through  (17)  of  the  meeting  report  are  not  reproduced. 


September  8,  1980 


MEETING  REPORT 


SUBJECT:  Data  Bus  Specification  Working  Group  Meeting  No.  1 

DATE:  September  3-4,  1980 

IOCATION:  ARINC  Research,  Annapolis,  Md . 

ATTENDEES:  See  Enclosure  (1) 

ENCLOSURES:  (1)  Attendees 

(I)  Agenda 

(3 ;  Combat  System  Data  Bus  Interface  Specification  (Prelim) 

(ii  DDG’.  Overview 

(5:  DDGX  (3A)  Notional  Combat  System  Configuration  Alternates 
ft:  "1SWC  Presentation  by  Dan  Green 

(7)  APL  Presentation  by  Tom  Sleight 

(8)  NOSC  Presentation  by  Dale  Bowman 
<-t)  NOSC  Presentation  by  Bob  Reed 

(10)  NUSC  Presentation  by  Chuck  Arnold/Dave  Watson 

(11)  ARINC  Presentation  by  Chuck  Lacijan 

(12)  NSWe  Specification  Viewpoints 

(13)  APL  Specification  Viewpoints 

(14)  Specificity  of  Existing  Data  Bus  Systems 

(15)  Interconnection  Architecture  Model  Report,  BGS  Systems 
Inc.,  September  1979 

(16)  Functional  Requirements  for  Interfacing  with  Local  Area 
Networks 

(17)  Proposed  BOA  Statement  of  Work 

1.  This  report  contains  the  working  notes  of  the  September  3-4,  1980  meeting 
of  the  Data  Bus  Specification  Working  Group,  and  is  intended  for  internal 
working  group  records.  Attendees  are  listed  in  enclosure  (1). 

2.  This  was  the  first  meeting  of  the  Data  Bus  Specification  Working  Group. 
The  group  was  welcomed  to  ARINC  Research  by  Max  Duncan,  Vice-President 
and  Manager  of  the  Ships  and  Ordnance  Division.  The  meeting  was 
co-chaired  by  Tom  Sleight,  APL  and  Dan  Green,  NSWC,  Dahlgren.  Tom 
Sleight  presented  the  agenda,  enclosure  (2),  and  explained  the  purpose 
of  the  meeting.  The  agenda  was  designed  to  present  an  overview  of  the 
DDGX  and  the  participating  laboratories,  followed  by  specification 
viewpoints  from  NSWC  and  JHU/APL.  The  second  day  was  planned  for  a 
discussion  of  NOSC  efforts  and  splinter  group  meetings. 

3.  Tom  Sleight  handed  out  a  copy  of  the  preliminary  Combat  System  Data  Bus 
Interface  Specification  Plan  to  be  presented  for  Capt.  Holloway's 
approval,  enclosure  (3).  He  noted  the  purpose  of  the  plan  was  to 
develop  GFI  for  data  bus  application,  not  to  develop  a  GFE  data  bus. 

The  use  of  the  data  bus  is  planned  for  computers  and  peripherals,  as 
opposed  to  ship’s  data.  The  DDGX  program  wants  to  pay  industry  to 
participate  in  the  specification  development  process. 
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4. 


Bob  Hill  made  the  presentation  of  the  DDGX  overview,  enclosure  (4) , 
describing  a  50  ship  program  over  12  years  with  contracting  of  the 
lead  ship  in  1985.  He  emphasized  a  balance  is  being  sought  between  the 
practical  needs  for  the  first  ship  and  the  long  term  needs  for  the 
class.  A  handout,  enclosure  (5),  contains  examples  of  alternate 
combat  system  configurations  considered  for  DDGX.  Both  point-to-point 
wiring  and  data  bus  applications  were  illustrated.  He  emphasized  that 
NSWC  is  the  technical  support  agency  (TSA)  and  will  be  a  focal  point 
for  combat  system  engineering. 

5.  The  next  set  of  presentations  was  made  by  the  participating  laboratories 
to  acquaint  the  working  group  with  each  organization  and  any  data  bus 
experience  they  may  have.  Dan  Green  gave  the  NSWC  presentation, 
enclosure  (6) ,  and  noted  that  the  data  bus  is  a  tool  of  combat  system 
designers,  and  not  a  combat  system  design.  Tom  Sleight  made  the 
Applied  Physics  Lab  (APL)  presentation,  enclosure  (7),  discussing  data 
bus  and  distributed  processing  activities  currently  ongoing  at  APL.  The 
NOSC  presentation  was  made  in  two  parts;  Dale  Bowman  presented  enclosure 
(8),  stressing  the  need  to  look  at  the  total  data  distribution  system 
consisting  of  hardwired,  switched,  and  bussed  elements,  and  Bob  Reed 
presented  enclosure  (9) ,  describing  the  Ships  Data  Multiplex  System 
(SDMS)  and  the  low-level  serial  switch.  The  NUSC  presentation  was  made 
by  Chuck  Arnold  of  the  New  London  laboratory  and  Dave  Watson  of  the 
Newport  laboratory,  each  discussing  the  organization  and  experience  of 
their  respective  organizations.  Enclosure  (10) ,  a  NUSC  organization 
chart,  was  presented.  Chuck  Lacijan  made  the  ARINC  Research  presentation, 
enclosure  (11) ,  showing  ARINC  Research  experience  and  skills  in  related 
areas. 

6.  At  the  conclusion  of  the  laboratory  presentations,  a  discussion  was  held 
on  the  Data  Bus  Interface  Specification  Plan,  enclosure  (3).  Chuck 
Lawson  stated  that  the  scope  of  the  plan  should  remain  as  is,  and 
future  efforts,  such  as  looking  at  other  data  distribution  elements, 
could  possibly  be  added  for  FY  82.  Some  discussion  took  place  on  whether 
the  end  product  of  the  specification  was  a  bus  or  an  interface  to  a  bus. 

It  was  clarified  that  the  specification  is  for  a  data  bus.  Other 
concerns  raised  about  the  plan  were: 

.  a  validation  process  is  required  before  giving  equipment  to  an 
integrator 

.  the  specification  should  not  match  an  existing  industry  product 

.  the  criteria  and  schedule  for  industry  involvement  needs  to  be 
established 

.  NAVMAT  regulations  may  cause  any  required  bus  controller  to  be  a 
AN/UYK-44 
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In  response  to  the  concerns  about  industry  involvement,  Chuck  Lawson 
described  how  he  will  use  a  Basic  Ordering  Agreement  to  get  industry 
participation,  and  noted  that  a  general  task  statement  for  the  BOA 
should  be  developed  by  the  working  group. 

Dan  Green  presented  NSWC 1 s  specification  viewpoints,  enclosure  (12). 

He  made  the  points  that  the  problem  is  current  and  of  significant 
magnitude,  and  gave  two  examples  of  what  the  AEGIS  combat  system  would 
look  like  if  a  data  bus  was  used.  The  ISO  reference  model  was  given 
as  an  example  of  an  issue  that  should  be  addressed. 

Al  Davidoff  presented  APL's  specification  viewpoints,  enclosure  (13). 

Issues  presented  were  the  level  of  specificity  and  whether  terminals 
would  be  internal  or  external.  Jack  Prink  followed-up  with  a  presentation, 
enclosure  (14),  on  the  specificity  of  existing  systems,  such  as 
MIL-STD-1553  and  the  Digital  Avionics  Information  System  (DAIS).  Chuck 
Arnold  stated  that  the  ISO  model  was  adopted  to  minimize  line  costs,  and 
local  networks,  such  as  a  data  bus,  represent  a  different  problem.  He 
doesn't  think  we  should  necessarily  adopt  the  ISO  model  as  a  starting 
point,  and  offered  a  model  with  nine  layers  of  protocol,  as  contained 
in  enclosure  (15) •  The  IEEE  effort  to  establish  a  standard  for  inter¬ 
facing  with  local  area  networks,  enclosure  (16) ,  was  also  discussed. 

The  meeting  was  adjourned  after  a  short  discussion  of  the  splinter  groups 
needed  for  the  following  day's  meeting. 

The  second  day's  meeting  was  opened  with  a  discussion  of  the  purpose  and 
membership  of  the  splinter  groups.  The  following  splinter  groups  were 
established: 

A.  Scope  of  application  (benchmarks) /DDGX  data  needs 

.  John  Holmes 
.  Jack  Frink 
.  Bob  Heed 

B.  BOA  Statement  of  Work  (industry  contracts) 

Chuck  Lawson 
.  Dan  Green 
.  Bob  Harper 

C.  Reference  Model  (Specif icity/ISO) 

.  Al  Davidoff 
.  Chuck  Arnold 
.  Dale  Bowman 


D.  Internal  Working  Group  Plan 

.  Tom  Sleight 
.  Al  Bernard 
.  Chuck  Lacijan 
.  Don  Doherty 
.  Dave  Watson 


After  separate  meetings  each  splinter  group  made  reports  to  the 
full  working  group.  A  narrative  summary  of  each  report  is  contained 
below: 

A.  Scope  of  application 

The  DDGX  data  transfer  should  be  characterized,  identifying  such 
elements  as  word  size,  message  size,  frequency,  time  criticality, 
and  number  of  sources  and  sinks.  AEGIS  and  possibly  other  ship 
classes  such  as  carriers  and  submarines  should  also  be  examined 
to  determine  current  requirements.  An  explicit  effort  will  be  made 
to  determine  future  requirements.  Bus  performance  capability  should 
then  be  synthesized.  The  TSA  was  identified  as  a  resource  to  support 
these  tasks. 

B.  BOA  Statement  of  Work  (SOW) 


A  copy  of  the  SOW  developed  by  this  working  group  is  contained  in 
enclosure  (17).  Comments  were  provided  at  the  meeting.  All  subse¬ 
quent  comments  should  be  provided  to  Chuck  Lawson,  06D. 

C.  Reference  Model 


This  working  group  reached  the  following  consensus: 

.  The  layered  interface/protocol/control  ops  concept  should  be  main¬ 
tained  . 

.  The  distinction  between  external  terminal  and  dedicated,  embedded 
terminal  should  be  maintained. 

.  The  distinction  between  computer  and  non-computer  subscribers 
should  be  maintained. 

.  The  word  interface  should  be  eliminated  from  the  specification 
plan,  enclosure  (3) . 

.  We  should  track  and  participate  in  IEEE  and  other  non-proprietary 
standard  efforts  commensurate  with  schedule. 

.  Use  "waterman"  and  "otherman"  reference  models  for  identifying  proto¬ 
cols,  interfaces,  and  control  ops  needed  at  each  level.  This  task 
will  be  accomplished  by  a  multiple  lab  effort  before  the  next  work¬ 
ing  group  meeting. 

.  At  the  next  working  group  meeting,  select  1  reference  model  as  the 
basis  for  strawman  development .  This  may  undergo  an  iteration  from 
meeting  no.  2  to  meeting  no.  3. 

.  Subsequent  to  above,  reorganize  subcommittees  for  strawman  development. 
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D.  Internal  Working  Group 

The  internal  working  group  should  become  a  permanent  subcommittee 
that  maintains  a  "living"  plan  (POA&M)  that  is  presented  at  each 
working  group  meeting.  It  should  have  3  members  plus  co-chairmen 
who  meet  during  each  working  group  meeting.  It  will  start  work 
on  an  acquisition  strategy  and  end  product  definition.  It 
recommended  that  the  specification  plan  acknowledge  activity  beyond 
14  months  and  that  the  word  interface  be  deleted. 

There  was  general  agreement  that  the  specification  plan  should  be  modified 
as  recommended.  Points  of  contact  were  established  for  each  organization 
as  follows: 

NOSC  -  Dale  Bowman 
NUSC  -  Chuck  Arnold 
APL  -  Tom  Sleight 
NSWC  -  Dan  Green 
ARINC  -  Dan  Kober 

Dan  Kober  will  be  notified  by  each  subcommittee  chairman  of  all  subcommittee 
meetings  and  notify  Chuck  Lawson  of  same.  The  next  two  working  group  meet¬ 
ings  were  established  for  1-2  October  and  6-7  November,  both  at  ARINC  start¬ 
ing  at  0800.  All  those  presenting  vue-graphs  at  these  meetings  are  requested 
to  bring  at  least  one  hard  copy  of  the  material  presented  for  the  Secretariat. 


Drafted  by: 


C.  A.  Lacijan 
Secretariat 


Distribution: 

See  next  page 
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D.  Marlow,  NSWC 

D.  Watson,  NUSC/Npt 

J.  Holmes,  NSWC,  Code  N51 

A.  Davidoff,  APL 

J.  Frink,  APL 

R.  Reed,  NOSC 

V.  Meyer,  NSW C,  Code  G-22 

D.  Doherty,  NOSC  Code  824 

R.  F.  Rockwell,  ARINC  Research 

M.  C.  Duncan,  ARINC  Research 

N.  Smith,  ARINC  Research 
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Enclosure  1 


Name 

Activity 

Phone 

1. 

C .  Lawson 

NAVSEA  06DC1 

202 

692-7296 

2. 

R.  T.  Hill 

NAVSEA  06D6E 

202 

692-7347 

3. 

R.  F.  Rockwell 

ARXNC  Research  Corp. 

301 

266-4961 

4. 

M.  C.  Duncan 

ARINC  Research  Corp. 

301 

266-4900 

5. 

D.  Kober 

ARINC  Research  Corp. 

301 

266-4965 

6. 

D.  Watson 

NUSC/Newport,  R.  X. 

401- 

-841-3354 

7. 

A.  Bernard 

NAVSEA  PMS  408 

202 

692-8204 

8. 

D.  Green 

NSWC 

703- 

-663-7731 

9. 

J.  Holmes 

NSWC-N51 

703 

663-7431 

10. 

A.  Davidoff 

APL 

301 

593-7100 

X 

3250 

11. 

T.  Sleight 

APL 

301 

593-7100 

X 

7377 

12. 

J.  Frink 

APL 

301 

593-7100 

X 

3249 

13. 

C.  Lacijan 

ARINC  Research  Corp. 

301 

266-4972 

14. 

R.  Reed 

NOSC 

714 

225-6227 

15. 

Vic  Meyer 

NSWC  (G-22) 

A/V 

249-7861, 

C703-663 

16. 

D.  Bowman 

NOSC  Code  824 

714 

225-6284 

17. 

D.  Doherty 

NOSC  Code  824 

■'14 

225  -O'S 

18. 

C.  Arnold 

NOSC  Code  313 

203 

447-4319 

19. 

N.  Smith 

ARINC  Research  Corp. 

301-266-4822 

20. 

R.  Harper 

ARINC  Research  Corp. 

301- 

-266-4963 
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APPENDIX  B 


PROGRAM  PLAN  FOR  DATA  TRANSFER 
BETWEEN  COMBAT  SYSTEM  COMPONENTS 


This  appendix  reproduces  the  Program  Plan  for  Data  Transfer  Between 
Combat  System  Components,  prepared  by  the  Naval  Sea  Systems  Command,  Combat 
System  Engineering  Office. 
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FOREWORD 


This  plan  presents  a  program  for  the  development  of  an  inter-conputer/pe- 
ripheral  data  transfer  mechanism  specification  for  information  transfer 
between  combat  system  components  by  means  of  a  shared  data  path,  such  as  a  data 
bus.  This  specification  will  be  applied  initially  to  the  next  generation 
Guided  Missile  Destroyer,  DDGX. 
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CHAPTER  ONE 


INTRODUCTION 


1.1  PURPOSE 

The  purpose  of  this  plan  is  to  structure  a  program  for  the  development  of 
a  specification  for  a  mechanism  for  information  transfer  between  combat  system 
components  ( inter-computer /per ipheral  data- transfer)  by  means  of  a  shared  data 
path,  such  as  a  data  bus.  Figure  1  depicts  a  generic  data  bus  concept  as  an 
alternative  to  traditional  point-to-point  interconnections  used  with  weapons, 
sensors,  computers,  and  peripherals.  This  specification  will  be  applied  ini¬ 
tially  to  the  next-generation  Guided  Missile  Destroyer,  DDGX.  Concurrent 
efforts  will  develop  specifications  for  other  classes  of  ships  to  support  both 
new-construction  and  major-upgrade  programs. 


ponrr-m*onrr  data  bus 

(DEDICATED  " HARDWIRED ~  CONNECTIONS!  (SHARED  COMMON  BATHS! 


Figure  1.  ALTERNATIVE  TO  POINT-TO-POINT  INTERCONNECTIONS 


1.2  BACKGROUND 

There  is  great  interest  in  the  use  of  data  buses  as  an  alternative  to 
point-to-point  interconnections  in  surface  combat  systems.  In  1978,  the 
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Deputy  Assistant  Secretary  to  the  Navy  (Research,  Engineering  and  Sys teas) 
sponsored  a  Data  Bus  Panel  to  investigate  the  issues.  The  Air  Force  has  almost 
ten  years'  experience  employing  MIL-STD-1553  as  a  Government-furnished  infor¬ 
mation  (GFX)  data  bus  standard.  The  Naval  Air  Systems  Command  (NAVA1R)  cur¬ 
rently  is  adopting  the  same  approach  in  the  F-18,  which  uses  two  AN/AYK-14s 
with  MIL-STD-1553  interfaces.  In  addition,  the  Navy  AN/UYX-43  and  AN/DYK-44 
computer  procurements  will  provide  this  bus  interface  option,  as  well  as  other 
point-to-point  interfaces,  like  STANAG  4153,  that  are  suitable  interfaces 
between  components  and  external  terminals.  Commercial  airline  manufacturers 
began  employing  data  bus  standards  more  than  20  years  ago.  Industry  is 
actively  pursuing  independent  research  and  development  (IRfcD)  programs  to  gain 
a  technical  understanding  of  bus  applications  and  to  prepare  for  future  system 
procurements. 


Although  the  advantages  of  using  a  data  bus  throughout  a  combat  system  are 
yet  to  be  validated,  it  is  clear  that  some  major  applications  of  limited  scope 
will  be  practical  in  the  near  future  and  have  the  potential  of  providing 
substantial  benefits  to  the  Navy. 

Distributed  data  processing  with  data  busing  has  the  potential  for  solv¬ 
ing  several  problems,  two  of  which  are  discussed  here.  First,  computations 
required  for  the  DDGX  type  combatant  are  beyond  the  capability  of  even  the 
fastest  single-processor  computer.  Thus,  it  is  already  necessary  to  employ 
simultaneous  processing  in  a  great  number  of  interconnected  processors. 
Faster  circuits,  e.g.,  very  high  speed  integrated  circuits  (VHSIC) ,  are  being 
researched  but  will  not  be  available  for  application  before  the  1990s.  Even 
then,  the  growing  complexity  of  the  problem  may  still  require  multiple  pro¬ 
cessors.  An  additional  problem  is  that  the  adaptation  of  existing  equipment  to 
meet  more  intense  threats  is  leading  to  increasingly  complex  designs.  More 
adaptable  and  extensible  approaches  are  necessary. 

There  exists  for  newer  ship  classes  a  reasonably  well  defined  functional 
hierarchy  of  systems  and  equipments: 


Level  I 
Level  II 
Level  III 

Level  IV 


Total  ship 

Ship  functions  (e.g.,  combat  system,  mobility) 

Subsystem  or  component  (e.g. ,  a  total  warfare  area  weap¬ 
on  system) 

Elements  (e.g.,  a  radar,  launcher,  or  sonar) 


For  lower-tier  (Level  IV)  elements  in  the  hierarchy,  engineers  have  already 
chosen  distributed  processing  and  busing  as  effective  solutions  to  require¬ 
ments.  For  example,  subsystems  of  the  vertical  launch  system  (VLS)  and  the 
AEGIS  weapon  system  currently  employ  data  buses.  Problems  at  the  higher  tiers 
are  related  to  (1)  lack  of  a  recognized  central  authority  to  provide  the 
consistent  technical  direction  to  implement  distributed  processing  and  data 
busing  across  many  subsystems,  and  (2)  to  the  real-life  constraints  imposed  by 
the  use  of  existing  designs  and  computer  programs.  Therefore,  the  validity  of 
conclusions  is  heavily  dependent  on  the  level  investigated  in  this  hierarchy. 


DDGX  represents  a  current  opportunity  to  move  toward  distributed  process¬ 
ing  and  new  daca-trznemission  architectures.  The  ODGX  combat  system  is  being 


designed  to  provide  maximum  flexibility  for  system  and  element-level  hardware 
and  computer  program  upgrades  during  its  life.  The  combat  system  is  to  be 
designed  to  be  highly  survivable  and  to  have  a  maximum  number  of  alternative  or 
casualty  modes  of  operation.  To  support  these  concepts,  the  Navy  must  consider 
the  concepts  of  distributed  processing  and  a  compatible  data  transfer  system, 
as  well  as  traditional  point-to-point  connected  architectures,  in  the  design 
of  the  pDGX  combat  system.  The  Combat  System  Engineering  Agent  (CSEA)  for  the 
DDGX  program  needs  to  define  and  develop  the  requirements  for  an  advanced 
extensible,  flexible,  and  survivable  data-processing/data-transfer  architec¬ 
ture  suitable  for  use  throughout  the  entire  combat  system.  He  must  review 
applicable  Navy  data-handling  (data-processing/data-transfer)  developments 
and  make  appropriate  recommendations  (1)  to  ensure  proper  operation  of  the 
entire  ship  and  combat  system  data-handling  architectures  (wherein  many  "ship 
services"  functions  affect  the  combat  system)  and  (2)  to  ensure  system  flexi¬ 
bility  and  survivability.  The  defined  architecture  is  to  be  compatible  with 
AN/UYK-43/44  and/or  AN/UYK-7/20  standard  Navy  computers  and,  where  feasible, 
use  standard  Navy  languages,  executive  programs,  and  protocols.  This  effort 
provides  for  both  near-term  inclusion  in  the  combat  system  of  currently  planned 
elements  (near-term  inventory  items  that  are  candidates  for  first  ship  use)  and 
for  long-term  developments  of  combat  system  elements.  The  degree  to  which  such 
a  system  will  use  developmental  and/or  commercial  equipment  in  the  processing 
phases  of  land-based  test  and  evaluation  will  be  addressed  in  future  planning. 

Future  opportunities  will  be  in  the  Ship  System  Engineering  Standards 
(SSES)  program.  The  objective  of  the  SSES  program  is  to  achieve  physical  and 
functional  separation  of  the  platform,  hull,  and  its  payload  elements  (Level 
IV) .  Engineering  standards  will  be  developed  to  allow  the  design  and  construc¬ 
tion  of  the  platform  independent  of,  but  in  concert  with,  the  combat  system 
elements.  These  standards  will  be  the  basis  for  the  development  of  new  classes 
of  ships  that  are  designed  and  constructed  to  accomodate  easily  and  quickly, 
through  modular  interchangeability,  any  of  the  payloads  most  appropriate  to 
those  generic  platforms.  These  standards  will  also  be  implemented,  as  appro¬ 
priate,  in  the  conversion  and  modernization  of  existing  ships. 


1.3  SCOPE 

The  specification  effort  addressed  in  this  plan  will  define  the  mecha¬ 
nisms  necessary  for  the  components  (computer  program  modules  in  conputers  and 
peripherals)  that  are  a  part  of  weapon,  sensor,  and  control  subsystems  to 
comunicate  effectively  among  themselves.  To  this  end,  a  series  of  interfaces, 
protocols,  and  control  operations  will  be  specified.  This  effort  will  address 
both  the  situations  in  which  the  physical  structure  of  equipment  cosponents 
(e.g.,  AN/UYK-7)  cannot  be  cost-effectively  modified  and  the  situations,  such 
as  in  new  designs,  in  which  they  can  be. 

Figure  2  provides  a  simplified  representation  of  one  approach  to  the 
interfaces.  Where  a  data  transfer  terminal  must  be  added  externally,  as  to 
existing  equipment  using  a  current  MXL-STD-1397  or  the  new  STANAG  4153  inter¬ 
face,  the  user  interface,  the  external  terminal  interface,  and  the  connec¬ 
tor/cable  interface  will  be  specified  in  sufficient  detail  eo  that  there  can  be 
no  ambiguity  among  various  subscribers,  data  transfer  terminal  vendors,  and 
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connector /cable  vendors.  Where  the  data  transfer  terminal  is  added  inter¬ 
nally,  the  user  interface  and  the  connector /cable  interface  will  be  specified 
in  sufficient  detail  so  that  there  can  be  no  ambiguity  between  various  sub¬ 
scribers  and  connector /cable  vendors.  The  precise  control  operations  and 
interfaces  will  be  described  functionally,  specifying  minimum  performance 
requirements,  associated  protocols,  and  applicable  constraints  such  as  power, 
weight,  cabling,  size,  and  memory  requirements. 

EXTERNAL.  DATA  TRAK5FEB  TERMINAL  INTERNAL  DATA  TRANSFER  TERMINAL 


“SMART"  SUBSCRIBER  "SMART"  SUBSCRIBER 


DT  -  DATA  TRANSFER  . 

V - ■  DT  TRANSMITTER  j -  DT  TERMINAL 

A «  DT  RECEIVER  I 


SMART  SUBSCRIBER  -  WEAPON.  SENSOR.  COMPUTER.  PERIPHERAL  WITH  EMBEDDED 
PROCESSING  CAPABILITY 

E2  -  THIS  PORTION  OF  THE  INTERFACE  SPECIFIED  SUCH  THAT  NO  AMBIGUITY 
CAN  EXIST  AMONG  POTENTIALLY  DIFFERENT  SUBSCRIBER.  DT  TERMINAL. 
ANO  CONNECTOR/CABLE  VENDORS  AS  TO  WHAT  IS  MUTUALLY  EXPECTED 
ACROSS  THE  INTERFACE 


Figure  2.  EXAMPLE  OF  INTERFACE  RELATIONSHIPS 

With  well  defined  interfaces  and  protocols,  and  functionally  defined 
"black  boxes"  between  interfaces,  this  specification  will  permit  effective 
competitive  procurement  of  system  elements  with  a  common-path  interconnection, 
if  desired  by  the  developer.  Such  freedom  of  implementation  should  permit  the 
future  evolution  of  effective  common  paths  throughout  a  combat  system.  Figure 
3  depicts  the  potential  variability  in  data  transfer  implementation  in  accord¬ 
ance  with  the  approach  outlined  in  Figure  2,  showing  different  subscribers, 
different  data  transfer  terminals,  and  connectors  and  cables  supplied  by  dif¬ 
ferent  vendors. 

The  technical  and  management  insight  gained  by  NAVAIR  and  the  Air  Force  in 
the  use  of  the  Government-furnished  information  (GFI)  MIL- STD-1553  avionics 
bus  will  be  an  important  factor  in  the  development  of  this  specification. 


Coonon  user  interfaces,  future  subsystem  introduction,  and  technology  inser¬ 
tion  will  be  high-priority  factors  considered  in  the  protocol  deliberations. 

In  carrying  out  the  detailed  deliberations,  it  will  be  necessary  to  con¬ 
sider  cabling  technology  (copper  and  fiber  optics) ;  industry  XR&D  projects; 
standardization  efforts  by  the  North  Atlantic  Treaty  Organization  (NATO) , 
techhnical  societies,  the  National  Bureau  of  Standards,  and  industry;  com¬ 
patibility  with  a  variety  of  combat  system  architectures;  effect  of  applica¬ 
tion  and  executive  computer  programs;  and  all  hardware  and  software  aspects,  of 
input/output  (1/0)  structure  and  ship  signal  data  transfer  interfaces. 


0  DIFFERENT  SUBSCRIBERS 

(SOME  DT  TERMINALS  INTEGRATED  WITHIN  SUBSCRIBER  HARDWARE) 

( 2 )  DIFFERENT  DT  TERMINALS 

(IDENTICAL  INFUT/OUTPUT  ATTRIBUTES) 

0  DIFFERENT  VENDOR  SUPPLIED  CONNECTORS  ft  CABLE 
(IDENTICAL  PHYSICAL  ATTRIBUTES) 


Figure  3.  EXAMPLE  OF  DATA  TRANSFER  IMPLEMENTATION  VARIETY 

Except  as  indicated  above,  this  effort  will  not  directly  specify  such  far- 
reaching  areas  as  combat  system  architectures,  computer  architectures,  com¬ 
puter  programming  languages,  Navy  standard  computer  and  peripheral  acquisi¬ 
tions,  and  ship  signal  data  transfer  systems. 
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CHAPTER  TWO 


MANAGEMENT 


2.1  OVERVIEW 

The  management  organization  for  the  development  of  the  data  transfer 
specification  is  designed  to  provide  interaction  between  combat  system  users, 
engineers.  Navy  system  acquisition  managers  and  the  DDGX  CSEA.  A  Data  Transfer 
specification  working  'group  {DTSWG)  and  an  advisory  panel  will  be  formed. 


2.2  DATA  TRANSFER  SPECIFICATION  WORKING  GROUP 

The  primary  objective  of  the  DTSWG  is  to  produce  the  data  transfer  speci¬ 
fication.  The  group  will  consist  of  technical  personnel  from  Naval  Sea  Systems 
Command  (NAVSEA) ,  Naval  Surface  weapons  Center  (NSWC) ,  Naval  Ocean  Systems 
Center  (NOSC) ,  Naval  Underwater  System  Center  (NUSC) ,  Johns  Hopkins 
University /Applied  Physics  Laboratory  (JHU/APL) ,  ARZNC  Research  Corporation, 
and  the  DDGX  CSEA. 

Industrial  activities.  Navy  acquisition  managers  concerned  with  data 
transfer  development,  and  combat  system  engineers  will  be  solicited  for  user 
requirements  and  technical  comments.  NAVSEA  06DC  will  chair  the  working  group; 
ARINC  Research  will  provide  the  secretariat  for  the  working  group  and  will,  at 
the  direction  of  the  chairman,  maintain  minutes  of  the  meetings,  develop  and 
distribute  meeting  agendas,  and  review  and  consolidate  industry  comments  con¬ 
cerning  the  specification  as  it  is  being  developed. 


2.3  ADVISORY  PANEL 

The  purpose  of  the  advisory  panel  is  to  conduct  in-progress  reviews  of  the 
DTSWG  efforts  and  to  provide  guidance  as  necessary.  The  panel  will  be  chaired 
by  SEA-06D  and  will  initially  include  representation  from  SEA-313,  -61,  -62, 
-63,  -06DC,  -Q6D6,  PMS-400,  and  PMS-408. 
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CHAPTER  THREE 


APPROACH 


3.1  OVERVIEW 

The  approach  to  developing  the  data  transfer  specifications  will  be  to 
establish  alternate  technical  approaches  (known  as  strawmen)  and  —  through  an 
iterative  review  process  with  assistance  from  industry,  potential  data  trans¬ 
fer  producers,  and  Navy  system  engineers  and  acquisition  managers  — reach 
agreement  on  a  final  specification.  In  order  to  bound  the  approach,  review 
will  focus  on  combat  system  elements  planned  for  DDGX  and  SSES  ships.  This 
plan  addresses  only  the  development  of  the  data  transfer  specifications  for 
DDGX  and  SSES  ships.  Subsequent  plans  will  address  validation  and  later  phases 
of  this  project. 


3.2  SCHEDULE 

The  approach  described  herein  is  expected  to  take  16  months  after  initia¬ 
tion  and  is  predicated  on  involvement  by  industry  and  Navy  acquisition  man¬ 
agers.  figure  4  illustrates  the  program  schedule.  Subsequent  paragraphs 
discuss  each  event  shown  in  Figure  4. 


riyurm  4.  DATA  TRANSFER  SPECIFICATION 
WORKING  GROUP  SCHEDULE 
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3.3  APPLICATION  SCOPING 


The  initial  tasfc  for  the  DTSWG  will  be  to  focus  on  projected  Navy  combat 
system  requirements  and  develop  an  initial  set  of  requirements  for  the  data 
transfer  specifications.  Together  with  the  application  studies,  these  will  be 
used  later  to  refine  the  requirements. 


3.4  DATA  COLLECTION 

In  order  to  assure  a  good  engineering  foundation,  data  will  be  collected 
on  data-exchange  requirements,  such  as  data  rates,  acceptable  delays,  message 
size,  message  traffic/  and  acceptable  error  rates.  This  effort  will  be  re¬ 
stricted  to  the  elements  expected  in  the  combat  systems.  The  exact  parameters 
of  combat  system  elements  will  not  be  known  for  some  time,  but  existing  imple¬ 
mentations  of  elements  of  other,  combat  systems  can  be  examined.  Khere  com¬ 
pletely  new  elements  are  expected,  the  DTSWG  must  rely  on  engineering  judgment. 
In  order  to  obtain  the  necessary  data,  the  assistance  of  various  Navy  partici¬ 
pating  managers  (PARM)  and  element  contractors  will  be  requested. 


3.5  STRAWMEN/DRAFT  SPECIFICATIONS  DEVELOPMENT 

At  least  three  data  transfer  strawmen  will  be  developed  for  DDGX,  of  which 
one  will  be  the  Standard  Information  Transfer  Architecture  for  Combat  Systems 
(SITACS)  developed  by  NAVSEA-61.  The  strawmen  will  be  modified  a3  necessary  to 
represent  additional  or  different  requirements  for  other  class  ships  as  part  of 
SSES .  The  strawmen  will  represent  alternate  technical  approaches  for  use  with 
DDGX  and  SSES  as  appropriate.  They  will  be  forwarded  to  Navy  system  acquisi¬ 
tion  managers  and  to  industry  for  review.  As  the  design  progresses  and  com¬ 
ments  are  received,  a  draft  specification  will  be  developed  from  each  strawman 
to  further  define  each  technical  approach.  These  draft  specifications  will  be 
forwarded  for  comment  to  the  members  of  the  Navy  and  industrial  team  who 
reviewed  the  strawmen. 


3.6  DDGX/SSES  APPLICATION  ANALYSES 

The  strawmen,  draft  specifications,  and,  ultimately,  the  final  specifica¬ 
tion  will  be  examined  for  suitability  of  application  to  the  DDGX  combat  system. 
Items  such  as  ship  schedule,  development  time,  cost,  combat  system  design 
alternatives  incorporating  data  transfer  systems,  producibility,  and  advan¬ 
tages  or  disadvantages  to  DDGX  of  the  various  strawmen,  draft  specifications, 
and  final  specification  will  be  analyzed.  This  work  will  be  performed  by  the 
DDGX  Combat  System  Engineering  Office,  Technical  Support  Agent,  Combat  System 
Engineering  Agent,  consultants,  and  industry  representatives  familiar  with 
combat  system  elements  and  data  transfer  implementations;  guidance  and  direc¬ 
tion  will  be  provided  by  the  DTSWG.  Any  additional  factors  pertinent  to  SSES 
will  be  analyzed  by  the  DTSWG ,  consultants,  and  industry  representatives  fa¬ 
miliar  with  combat  system  elements  and  data  transfer  implementations  in  coor¬ 
dination  with  SEA-06DC. 
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3.7  INDUSTRY  AND  ACQUISITION  MANAGER  REVIEWS 

Timely  reviews  will  be  solicited  from  both  the  data  transfer  user  com¬ 
munity  (i.e.,  applicable  system  and  subsystem  acquisition  managers  and  their 
industry  contractors)  and  the  data  transfer  producing  community  (i.e.,  appro¬ 
priate  industry  data  transfer  developers) .  Following  receipt  of  formal  writ¬ 
ten  reviews  of  the  strawmen  versions  and  draft  specifications,  the  DTSWG  will 
invite  the  reviewers  to  report  orally.  All  reviewers  are  expected  to  quantify 
alternatives  and  be  prepared  to  discuss  their  selections.  Open  technical 
discussions  will  be  encouraged. 


3.8  REVIEW  MEETINGS 

The  first  meeting  will  be  held  following  DDGX,  industry  and  acquisition 
management  review  of  the  strawmen.  Following  consideration  of  the  comments, 
the  DTSWG  will  propose  a  single  draft  specification,  which  will  be  distributed 
for  review;  another  user-producer  meeting  will  then  be  convened. 

The  DTSWG  will  establish  agenda  items  that  address  various  aspects  of  the 
proposed  strawmen  or  specifications.  The  secretariat  will  provide  the  agenda 
to  the  potential  meeting  attendees  when  the  meeting  is  announced.  During  the 
review  meetings,  attendees  will  discuss  their  concerns  and  subcommittees  will 
be  established  to  rewrite  portions  of  the  strawmen  or  draft  specifications  so 
that  controversies  or  conflicts  can  be  resolved  during  succeeding  days  of  the 
meeting.  An  advisory  panel  will  meet  to  review  progress  of  the  DTSWG  as 
requested  by  the  chairman,  SEA-06D. 


3.9  DDGX  SPECIFICATION  DEVELOPMENT 

A  specification  for  a  mechanism  for  transfer  of  DDGX  intercomputer /per i- 
pheral  data  will  be  prepared,  incorporating  the  consensus  developed  during  the 
reviews  of  the  strawman  specifications.  This  DDGX  specification  will  be  for¬ 
warded  to  the  DDGX  CSEA  for  implementation. 


3.10  SSES  SPECIFICATION  DEVELOPMENT 

Changes  necessary  to  accommodate  combat  systems  of  other  classes  of  ships 
will  be  made  to  the  DDGX  specification  to  support  its  use  in  the  SSES  program. 
These  changes  will  satisfy  information-transfer  requirements  of  differing  com¬ 
bat  system  architectures  not  met  by  the  DDGX  specification.  The  specification 
will  then  be  forwarded  to  NAV5EA-313. 
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APPENDIX  C 


CONFERENCE  MINUTES  FOR  THE  SHIP  SYSTEM  INTEGRATION, 
INCLUDING  COMMAND  AND  CONTROL  CONFERENCE 


This  appendix  presents  the  minutes  of  a  tri-nation  conference  (United 
States,  Canada,  and  Germany)  to  discuss  distributed  processing  and  data 
busing  for  ship  systems. 
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CONFERENCE  MINUTES  FOR  THE 


SHIP  SYSTEM  INTEGRATION  INCLUDING  COMMAND  AND  CONTROL  CONFERENCE 
(NATIONAL  CENTER  #2  ON  3  S  4  March  1981) 


Attachment (s)  (1)  Conference  Agenda 

(2)  Attendees  -  3  March  1981 

(3)  Attendees  -  4  March  1981 

TUESDAY,  March  3,  1981 

Capt.  R.  Rodgers  opened  the  conference  with  a  welcome  to  the  German, 
Canadian  and  U.S.  attendees.  He  noted  that  the  intent  of  the  U.S.  Navy 
briefings  was  to  provide  information  concerning  the  U.S.  Navy  commitment 
to  distributed  processing/data  bussing.  He  requested  questions  on  an 
individual  briefing  be  asked  during  the  briefing  and  introduced  a  change  to 
the  agenda  provided  as  attachment  (1).  Mr.  R.  Hill  would  present  an  overview 
of  the  DDGX  design  as  the  first  briefing. 


DDGX  Design  Considerations 


Mr.  R.  Hill  introduced  the  DDGX  program  as  design  and  construction  of 
fifty  multi-mission  combatants  to  operate  in  Battle  Groups  which  would  also 
contain  AEGIS  ships.  He  discussed  the  background  leading  to  DDGX  and  the 
studies  on  methods  of  data  transfer  which  were  conducted  as  part  of  the 
Combat  System  Architecture  (CSA)  program.  The  current  DDGX  design  philosophy 
stressed: 

.  quality  of  organizational  management 
.  quality  of  information  management 
.  flexibility  of  design 
.  flexibility  of  use 
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In  his  position  as  DDGX  Chief  Combat  Systems  Engineer,  he  is  calling  for 
sufficient  statistics  to  support  the  command  delegation  process  in  DDGX. 

Two  points  stressed  in  evolving  the  design  of  the  combat  system  for  DDGX  were 


.  principle  of  accessibility  of  data  in  making  command  decisions 

.  involving  personnel  in  NAVSEA  responsible  for  warfare  areas,  in 
invoking  design  principles 

Mr.  Hill  suggested  that  in  considering  the  battle  organization,  we  need  to 
answer  the  question  of  "What  do  the  humans  do?”  He  presented  a  functional 
flow  diagram  for  the  combat  system,  delineating  both  managerial  and  executive 
overtones  and  indicated  that  Government  contracted  efforts  will  be  utilized 
to  bring  together  system  development  towards  supporting  each  warfare  area 
including  the  networking  of  various  supportive  elements. 

Mr.  Hill  in  addressing  information  transfer/data  bussing,  introduced 
Mr.  C.  Lawson  as  the  coordinator  of  "CSA  turned  DDGX"  efforts,  in  pre¬ 
scribing  a  candidate  medium  for  information  tranfer  in  the  DDGX.  Mr.  Hill 
noted  that  data  bussing  will  not  save  space  and  weight  over  Low  Level  Serial 
(LLS) ,  but  should  offer  more  flexibility  especially  in  such  areas  as  recon¬ 
figuration.  The  lead  ship  may  use  LLS  but  the  class  in  general  should  use 
a  bussing  concept. 

When  questioned  as  to  what  a  CSEA  and  TSA  for  DDGX  were,  Mr.  Hill  pro¬ 
vided  the  following:  The  CSEA  or  Combat  System  Engineering  Agent  is  a  major 
industrial  contractor  to  be  brought  in  to  the  program  in  July  1981.  The 
contractor  will  be  responsible  for  the  systems  engineering  effort  necessary 
to  design  the  combat  system  for  DDGX.  The  contractor  will  be  administered 
and  generally  monitored  by  a  TSA  or  Technical  Support  Agent.  The  TSA  under 
NSWCi  Dahlgren  lead  will  consist  of  Government  laboratories  and  closely  held 
consultants. 


Distributed  Processing 


Dr.  T.  Sleight  and  Mr.  D.  Green  jointly  reviewed  the  subject  of 
Distributed  Processing.  Dr.  Sleight  led  off  with  an  overview  on  the 
status  of  technology.  He  noted  the  prior  John  Hopkins  University/Applied 
Physics  Laboratory  experience  in  data  bussing  including  their  current  use 
of  a  fibre  optic  bus,  and  the  varied  definitions  of  distributed  processing 
they  have  come  across.  He  proposed  that  a  layered  protocol  concept  is  the 
key  to  data  transfer  interoperability.  Additionally,  data  busses  should 
be  categorized  in  groups  by  their  bandwidth  characteristics  to  aid  in  com¬ 
parison.  The  associated  cost  of  implementing  a  data  bus  is  considered  to 
be  expensive  initially  but  lower  on  an  overall  basis.  CDR.  J.  Carruthers 
presented  the  viewpoint  that  the  cost  is  affected  by  the  actual  degree  of 
implementation  and  the  associated  management  concept. 

Mr.  Green  reviewed  the  distributed  processing  architecture  of  the  AEGIS 
Guided  Missile  Ship  -  CG  47.  He  discussed  the  AEGIS  ship  combat  system 
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from  the  view  point  of  a  computer  specialist.  Nr.  Green  emphasized  the 
current  issues  associated  with  combat  system  designs  as 

.  high  life  cycle  cost 

.  AN/UYK-7  limitations 

.  complexity  of  changes  where  interdependence  make  small  changes  large 
.  improved  fail/soft  capability  desired 
.  improved  survivability  desired 
.  weight  reduction  desired 
Re  stated  our  opportunities  to  include 

.  AN/UYK-43/44  currently  under  development 

.  NATO  Low  Level  Serial 
.  data  bus  technologies 

.  distributed  processing  technology  efforts 

His  approach  is  centered  on  the  position  that  within  a  class  of  ships,  all 
computers  look  identical  to  the  outside  world.  His  design  would  provide 
the  data  bus  as  a  computer  center  manager  from  a  functional  allocations 
view  point. 

Dr.  Sleight  then  summarized  the  briefings  with  a  discussion  on  combat 
system  evolution.  He  reviewed  the  internal  information  transfer  character¬ 
istics  of  the  AEGIS  combat  system.  From  a  practical  approach  he  stated  the 
need  to  gain  real  time  tactical  experience  in  DDGX,  with  the  data  bus  to  be 
introduced  as  an  acquisition  approach  for  new  elements  of  the  combat  system. 
A  question  was  asked  on  the  use  of  a  data  bus  for  elements  not  as  reliable 
as  computers.  It  was  noted  that  the  data  bus  could  not  only  interchange 
computing  facilities  which  are  highly  reliable,  but  the  input/output  (I/O) 
ports  which  are  not. 


P.S.  Navy  Data  Bus  Efforts 


Mr.  M.  Wapner  reviewed  the  research  and  development  programs  sponsored 
by  NAVSEA  61  in  information  transfer.  He  discussed  the  Shipboard  Distributed 
Multiplex  System  (SDMS) ,  as  a  general  purpose  data  bus  for  low  speed 
signals  (synchros,  analog  data,  discrete  signals).  It  is  currently  in  full 
scale  development  with  test  and  evaluation  planned  in  a  DD  963  class  ship 
in  fiscal  year  1982.  It  will  have  applications  in  both  submarines  and 
surface  ships. 


The  Advanced  Data  Transfer  System  was  presented  as  a  high  speed 
(greater  than  10  mbps)  system.  It  is  under  synthesis,  simulation  and 
analysis.  As  part  of  the  Foreign  Weapons  Evaluation  program  instituted  in 
January  1980,  they  are  establishing  information  transfer  requirements  based 
on  programs  underway  in  foreign  navys.  These  programs  include  Canadian- 
SH INPADS ;  French-Navy  CPN/DIGIBOS  (low  speed  multiplex),  T-CSF  Spiral 
(high  speed  distributed  network);  United  Kingdom  and  German  technologies. 

Mr.  Wapner  presented  the  time  schedule  for  O.S.  Navy  (DSN)  review  of 
SHINPADS  as 

.  quantification  of  DSN  data  loads  -  March  1981 

.  simulation  using  USN  data  -  April  1981 

.  hardware  evaluation  -  November  1981 

.  software  impact  evaluation  -  June  1982 

.  distributed  data  base  management  -  TBD 

.  hybrid  bus/network  experiments  -  TBD 

.  SHINPADS  protocal  evaluation  -  TBD 

He  discussed  the  differing  approaches  of  combat  system  design  driving 
information  system  transfer  architecture  versus  the  architecture  driving 
the  system  design.  A  middle  grounds  approach  was  suggested. 

Advanced  Sensor  Integration  Tactical  Data  Processing  (ASI/TDP)  Program 


Mr.  Phil  Andrews  presented  the  Advanced  Sensor  Integration  Tactical 
Data  Processing  (ASI/TDP)  program  underway  at  the  Naval  Ocean  Systems 
Center  (NOSC) .  Its  objective  is  to  establish  a  platform  level  technology 
base  in 

.  information  management 
.  combat  system  architecture 
.  shipboard  hardware/software  building  blocks 
.  system  controlability  (human  factors) 

Other  programs  underway  are 

.  Ship  Combat  System  Simulation  (SCSS)  -  development  of  a  model  to 
interact  node  -  message  -  data  relationships 

.  Lightweight  Modular  Display  System  -  intended  to  replace  the  AN/UYQ 
21  display 
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Mr.  Andrews  noted  that  an  architectural  iescription  should  include  a 
definition  of  each  subsystem  by  function, .including  the  methods  of  inter¬ 
connection.  He  stated  that  systems  integration  must  be  implicit  within 
combat  systems  design.  Questions  were  asked  on  training  and  standardiza¬ 
tion.  Mr.  Andrews  suggested  that  training  has  to  be  a  continuing  effort. 

The  quantity  of  maintenance  personnel  may  change  dependent  on  the  technology 
invoked,  but  a  trained  operator  is  still  a  necessity.  Capt.  Darwin 
explained  that  the  AN/UYQ-21  is  a  limited  application  standard.  He 
suggested  that  life  cycle  cost  savings  from  standardization  are  important 
but  its  emphasis  needs  to  be  recognized  and  evaluated  along  with  other 
factors  such  as  new  technology.  He  presented  a  brief  overview  of  the  Com¬ 
puter  Accreditation  efforts  as  a  means  of  achieving  standardization. 


Low  Level  Serial  Project 


Dr.  R.  Kolb  presented  the  background  and  status  of  the  Low  Level  Serial 
Project. 

Mr.  C.  Lawson  in  summarizing  the  earlier  briefings  noted  that  data 
bussing  has  and  currently  is  being  utilized  as  a  method  for  information 
transfer  in  Navy  ships.  He  reviewed  the  intent  and  activities  of  the  Data 
Bus  Working  Group  in  support  of  the  DDGX  program  and  indicated  the  need  to 
go  beyond  the  DDGX  and  consider  the  actual  battle  group.  In  addressing  this, 
he  welcomed  the  new  membership  of  NAVELEX  PME  108  in  the  working  group. 


WEDNESDAV,  March  4,  1981 


SITACS  -  Standard  Information  Transfer  Architecture  for  Combat  Systems 

Mr.  R.  Fastring  presented  the  concept  of  a  Standard  Information  Transfer 
Architecture  for  Combat  Systems  (SITACS) .  He  reviewed  the  before  (1972)  and 
now  shipboard  data  transfer  situation.  SMDS  was  designed  about  1972  with 
its  signal  requirements  not  well  quantified.  They  were  however,  reasonably 
bounded  and  not  too  sensitive  to  ship  or  combat  system  architecture.  The 
current  situation  still  shows  the  convential  signals  addressed  by  SDMS  but 
there  is  an  increasing  number  of  processor  signals  (non-SDMS) ,  and  more 
interest  in  distributed  processing.  In  reviewing  SITACS,  he  suggested  it 
offered  a  high  speed  interconnect  mechanism  for  Navy  combat  system  elements, 
with  sufficiently  high  modularity,  low  delay,  and  high  bandwidth  to  be 
relatively  insensitive  to  variations  in  combat  system  architecture.  He 
indicated  that  data  busses  did  not  provide  vertical  modularity  unless  a 
series  of  data  busses  were  employed  and  connected  by  gateways. 

SITACS  establishes  handshaking  on  a  real  end  to  end  basis,  but  the 
connection  is  by  trial  and  error  between  source  and  sink.  Time  delays 
measured  by  simulation  of  networks  including  up  to  seven  nodes  were  within 
that  allowed  by  STANAG  4153.  SITACS  has  limitations  in  both  the  broadcast 
mode  and  can  not  be  dynamically  reconfigured.  It  does  offer  however,  the 
use  of  STANAG  4153  Low  Level  Serial  interfaces  and  compatibility  with 
centralized,  near  term  federated,  and  ultimate  distributed  control  archi¬ 
tectures. 
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SHI HP ADS  -  Shipboard  Integrated  Processing  and  Display  System 


CDR.  J.  Cacruthecs  reviewed  development  and  current  status  of  the 
Shipboard  Integrated  Processing  and  Display  System  (SHXHPADS) .  Integration 
represents  a  severe  problem  in  ship  design  because  the  equipment  installed 
by  the  Canadian  Navy  is  multi-national.  The  use  of  SH INPADS  helps  to 
alleviate  this  problem.  Its  conceptual  design  is  based  on 

.  a  distributed  architecture 

.  use  of  standardized  displays,  computers,  software,  and  input/output 
port 

.  a  bus-structured  "ships”  central  nervous  system 

It  offers  a  flexible  system  of  fallback,  with  the  user  believing  he  is 
connected  by  dedicated  wire.  Future  efforts  are  to  productize  the  hardware, 
and  test  the  system  at  a  test  site.  SHINPADS  is  planned  to  be  used  in  the 
new  Canadian  Frigate  ship. 

Efforts  are  continuing  towards  design,  fabrication  and  environmental 
testing  of  engineering  development  models  of  a  multi-redundant  interdisplay 
system  to  provide  the  command  with  sufficient  information  to  operate  the 
ship  in  accordance  with  the  existing  threat.  Another  effort  under 
exploratory  development  is  digital  voice  multiplexing  for  integrated 
shipboard  communications  (general  telephone,  intercom,  conference  and  public 
announcement) .  Its  architecture  is  a  dual  star  distributed  network. 


Fibre  Optic  Communication  Network  (FOCON) 


The  German  presentation  reviewed  the  development  of  a  Fibre  Optic 
Communication  Network  (FOCON) .  The  starting  point  for  its  development  was 
consideration  of  voice  transmission  and  it  is  being  expanded  from  there. 

In  presenting  an  overview  of  their  ship  design  engineering,  they 
noted  determination  of  requirements  for  types  of  ship  systems  including 
the  use  of  data  busses  for  information  transfer.  It  is  based  on  an 
exchange  of  information  between  systems,  and  subsystems  structured  to 
enhance  the  capabilities  of  the  system.  The  results  are  provided  as  guide¬ 
lines  to  the  contractor  and  German  Navy  in  developing  subsystems. 


Working  Group  Session 

Subsequent  to  the  conference,  Capt.  R.  Rodgers  held  a  working  group 
session  to  review  the  accomplishments  and  determine  the  next  action.  He 
noted  that  the  conference  had  provided  an  information  exchange  on  "real" 
systems,  and  ideas  in  conceptual  and  hardware  aspects  of  research  and 
development.  He  suggested  that  there  are  many  technical  problems  and  issues 
and  the  key  to  solving  them  is  strong  management.  On  the  subject  of  where 
do  we  go  from  here,  CDR.  Carruthers  suggested  that  we  avoid  duplication  of 
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the  efforts  being  worked  by  the  Information  Exchange  Group  -  5,  Subgroup  6. 

Be  suggested  that  this  two  day  conference  was  to  expand  the  efforts  beyond 
the  Subgroup  6  activity.  He  considered  that  Rear  ADMS.  F.  G.  Fellowes,  Jr. 
(DSN) ,  D.  Wellershoff  (GN) ,  and  N.  D.  Brodeur  (CF)  agreed  to  this  meeting 
to  expedite  the  process. 

Capt.  J.  Darwin  noted  that- there  was  no  driving  force  leading  to  a 
single  approach.  Mr.  Lawson  noted  that  the  Assistant  Secretary  of  the  Navy 
had  provided  for  the  use  of  SDMS  and  others  as  necessary  to  support  combat 
system  design.  In  the  DDGX  program,  the  Combat  System  Engineering  Agent 
(CSEA)  will  review  the  development  plans  for  the  combat  system  and  the 
working  group  under  Mr.  Lawson  will  provide  guidance  in  the  area  of 
information  transfer.  He  suggested  that  the  SITACS  and  SHINPADS  concepts 
be  presented  to  his  working  group  for  consideration  in  DDGX. 

Discussions  centered  on  integrating  the  efforts  of  the  U.S.  Navy, 
Germany,  and  Canada  including  a  potential  joint  test  site.  Programs  like 
the  Advance  Combat  Direction  System  (ACDS)  were  suggested  as  candidate 
vehicles.  Capt.  Darwin  indicated  that  the  U.S.  has  not  yet  formulated  a 
position  on  this  matter.  The  German  representatives  indicated  the  same  for 
their  country.  CDR.  Carruthers  was  in  favor  of  a  joint  test  site  and  general 
joint  cooperation. 

In  discussing  the  NATO  Frigate  Replacement  for  the  1990's,  it  was 
suggested  that  a  joint  venture  be  started  and  include  other  nations  beyond 
those  at  this  conference.  It  was  recommended  that  the  DDGX  Information 
Transfer  Committee  Chairman,  Mr.  Lawson,  be  an  observer  at  the  forthcoming 
IEG-5  meeting  in  San  Diego  during  the  week  of  6  April. 

Administrative  Note  -  Attendees  to  the  3  and  4  March  1981  conference 
are  delineated  in  attachment  (2)  and  (3) . 
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APPENDIX  D 


MODELMAN  COMMUNICATIONS  REFERENCE  MODEL 
FOR  COMBAT  SYSTEM  DATA  TRANSFER 
(INTERCOMPUTER  AND  COMPUTER-PERIPHERAL) 


This  appendix  describes  a  communications  reference  model,  designated 
"Modelman,"  that  serves  as  an  organizing  construct  in  describing  data- 
transfer  mechanisms  for  use  in  U.S.  Navy  shipboard  combat  systems. 
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Section  1 


INTRODUCTION 


1.1  PURPOSE  OF  DOCUMENT 

This  document  describes  a  Communications  Reference 
Model,  titled  "Modelman",  that  serves  as  an  organizing 
construct  in  describing  data  transfer  mechanisms  for  use  in 
US  Navy  shipboard  cctnbat  systems.  V7hile  the  model  was 
developed  to  address  inter-ccmputer  and  computer-peripheral 
communications,  it  can  be  applied  to  intra-computer 
communications.  It  also  includes  guidance  in  developing  a 
communications  framework  for  a  specific  data  transfer 
mechanism  and  appendices  which  describe  functions 
representative  of  each  layer  of  the  model  and  possible 
hardware  examples. 


1.2  PURPOSE  OF  MODELMAN 


The  Modelman  Communications  Reference  model  has 
been  developed  to  address  data  transfer  requirements  of  US 
Navy  shipboard  combat  systems  —  characterized  by  a  realtime 
environment  which  requires  many  computers  to  cooperatively 
participate  in  communications  with  other  computers  and 
peripheral  devices  which  serve  those  computers  or  are 
interfaced  to  the  combat  system's  weapons  &  sensors.  Varied 
tactical  and  time-critical  tasks  are  being  performed 
concurrently  in  each  computer.  The  Modelman  Reference  Model 
serves  to  specifically  fulfill  the  following  objectives: 

(1)  Provide  understanding  by  establishing  a  common  set 
of  terms  and  definitions  about  US  Navy  shipboard 
Combat  System  data  transfer  mechanisms; 

(2)  Facilitate  data  transfer  mechanism  evolution  by 
promoting  the  use  of  common  logical  partitioning 
(layered  protocols)  to  physical  partitioning  of 
hardware  and  software; 


(3)  Serve  as  an  organizing  principle  for  the 
generation  of  the  communications  framework  for 
alternative  data  transfer  mechanisms  for  Guided 
Missile  Destroyer  DDGX  and  Ship  System  Engineering 
Standards  (SSES)  applications; 

(4)  Serve  as  a  basis  to  compare  existing  data  transfer 
mechanisms ; 
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(5)  Serve  as  a  descriptive  mechanism  for  future  data 
bus  specifications  thus  permitting  evolutionary 
change  by  maintaining  layer  integrity. 

Thus,  rather  than  being  a  specification,  Modelman  serves  as 
a  unifying  tool  in  the  development  of  data  transfer 
mechanisms. 


1.3  RELATIONSHIP  TO  OTHER  REFERENCE  MODELS 

The  International  Standards  Organization  (ISO)  has 
completed  its  sixth  formal  draft  of  a  reference  model  for 
telecommunications  applications .  The  Modelman  has  evolved 
from  the  ISO  reference  model,  maintaining  many  features  of 
that  draft  standard  in  spirit,  but  deviating  where  necessary 
to  reflect  the  US  Navy  real  time  system  environment.  The 
relationship  of  Modelman  to  the  ISO  efforts  is  further 
discussed  in  Appendix  C.  Modelman  also  bears  resemblance  to 
a  draft  model  emerging  from  the  IEEE  Standards  Project  802 
charged  with  developing  a  local  area  network  standard. 


1.4  DEFINITIONS 

The  following  definitions  are  provided  and  used 
throughout  the  document.  For  commonality,  these  definitions 
should  also  be  used  in  developing  the  communications 
framework  of  a  data  transfer  mechanism. 


1-4.1  Data  Transfer  Mechanism  -  The  means  by  which  data 
is  exchanged  in  intercomputer  and  computer-peripheral 
ccminunication .  Each  particular  data  transfer  mechanism  will 
consist  of  its  own  physical  and  logical  means  of  data 
exchange . 


1.4.2  Protocol  -  The  convention  or  set  of  conventions 
which  provide  for  the  orderly  exchange  of  data  between  peer 
layers  of  a  data  transfer  mechanism. 


1.4.3  Interface  -  The  local  boundary  between  contiguous 
layers  of  a  data  transfer  mechanism.  This  boundary  is  the 
sole  point  of  interaction  between  those  two  layers. 


1.4.4  Segmenting  -  Dividing  large  data  buffers  from 
other  (usually  higher)  layers  into  data  buffers  appropriate 
to  the  layer  performing  the  segmenting  operation. 
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1*4.5  Blocking  -  Constructing  data  buffers,  appropriate 
to  the  layer  performing  the  blocking  operation  from  smaller 
data  buffers  of  other  (usually  lower)  layers.  Blocking  is 
often  the  reconstruction  of  a  large  data  buffer  that  was 
sent  in  a  segmented  form. 


1.4.6  Peripheral  Functions  -  Tasks,  performed  by  the 
peripheral  devices  which  use  the  data  transfer  mechanism. 
(See  Appendix  B) . 


1.4.7  Tactical  Application  Software  -  User-level 
software  which  performs  a  tactical  function.  Tactical 
application  software  modules  originate  and  are  the  final 
destination  for  data  buffers. 


1.4.8  Subscriber  Service  Software  -  User-level  software 
which  provides  data  transfer  mechanism  services  to  external 
units  or  peripheral  functions .  Subscriber  Service  Software 
Modules  do  not  originate  data  buffers.  Bather,  this 
software  translates  and  passes  buffers  to  or  from  external 
equipment  which  is  not  capable  of  directly  using  the  data 
transfer  mechanism  in  question. 


1.4.9  Communications  Framework  -  A  basic  implementation 
of  the  Reference  Model  which  serves  as  the  foundation  for 
strawman  data  transfer  mechanisms.  The  framework  includes 
the  critical  components  of  each  layer,  and  defines 
sublevels,  if  any,  for  each  layer  (See  Appendix  ") . 


1.4.10  Machine 


A  hardware  device  which  has  resident  within  it  all 
that  is  needed  to  perform  one  side  of  the  protocols  defined 
by  one  of  the  Modelman  layers.  A  machine  may  perform  more 
than  one  level  of  control. 


1.4.11  Peer  Layers 

A  set  of  layers  at  the  same  level  in  the  model. 

1.4.12  Subscriber 


The  ultimate  computer  or  peripheral  user. 
Subscribers  are  considered  the  physical  units  which 
originate  or  act  as  a  final  destination  for  data  buffers. 
(Refer  to  Appendix  f) . 


1.4. 13  Terminal 

A  unit  composed  of  the  hardware  and  software 
necessary  to  implement  at  least  the  Bus /Network  Control  and 
Physical  layers.  (Refer  to  Appendix  p) . 
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DESCRIPTION  OP  MODELMAN 


The  Modelman  is  built  upon  the  concept  of 
partitioning  the  conmunication  control  into  layers.  Each 
layer  contains  functions,  some  of  which  are  directly  related 
to  the  transfer  of  data,  and  others  which  perform  needed 
housekeeping  operations .  These  functions  are  performed  via 
coninunication  with  peer  level  functions  located  elsewhere, 
through  protocols  at  that  level .  The  protocols  are 
negotiated  through  the  services  provided  by  the  next  lower 
level . 

Modelman  is  composed  of  the  following  five  layers: 
User,  Conmunication  Services,  Conversation  Services, 

Bus /Network  Control,  ^nd  Physical  and  are  shown  in  Figure  1. 


2.1  USER  LAYER 

The  User  Layer  consists  of  user-specific  software 
which  requires  the  services  of  the  lower  layers  of  Modelman. 
This  software  includes  tactical  application  software  which 
directly  operates  on  the  data  being  sent  or  being  received. 
In  some  implementations ,  software  may  also  include 
subscriber  services  software  which  communicates  with 
equipment  outside  the  machine  where  the  particular  User 
Layer  is  resident.  Subscriber  services  software,  when  used, 
will  typically  communicate  with  peripheral  devices  and 
computers  that  do  not  have  the  capabilities  of  the  data 
transfer  mechanism  covered  by  this  model.  Many  user-level 
tasks  are  expected  to  operate  concurrently  within  the  same 
machine . 


2.2  COMMUNICATION  SERVICES  LAYER 

The  Communication  Services  Layer  provides  the  data 
transfer  primitives  to  the  User  Layer.  This  layer  performs, 
or  operates  in  conjunction  with  operating  system 
communication  control  functions.  It  responds  to  service 
requests  from  User  Layer  tasks.  It  characterizes  the 
services  provided  to  the  User  Layer  via  the  data  transfer 
mechanism.  The  Conmunication  Services  Layer  manages  the 
end-to-end  transfer  of  data  buffers  between  different  user 
modules.  Data  buffers  may  be  segmented,  blocked,  or  neither 
under  the  control  of  this  level. 
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2.3 


CONVERSATION  SERVICES  LAYER 


The  Conversation  Services  Layer  manages  the 
transfer  of  data  involved  with  individual  conversations. 

This  layer  establishes  and  maintains  "connections"  that 
provide  the  required  quality  and  type  of  service. 

Connections  are  accomplished  through  negotiation  with  peer 
conversation  services  resident  in  different  machines  (or  the 
same  machine  if  the  transfer  is  intra-computer) . 


2.4  BUS /NETWORK  CONTROL  LAYER 

The  Bus /Network  Control  Layer  performs  the  control 
functions  governing  the  use  of  the  data  transfer  mechanism's 
physical  medium.  This  layer  controls  when  a  sender 
transmits  his  data  when  a  receiver  may  receive  data. 
Distinctions  must  be  made  between  those  functions  that 
control  the  medium  and  those  that  provide  access  to  the 
medium. 


2.5  PHYSICAL  LAYER 

The  Physical  Layer  establishes  the  signal 
characteristics  as  well  as  the  medium 1 s  mechanical 
characteristics .  This  layer  ensures  bit-level  accuracy  of 
the  data  being  transferred. 
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APPLICATION  GUIDANCE 

As  described  previously,  Modelman  is  to  serve  as  a 
basis  to  generate  data  transfer  mechanisms.  For  Modelman  to 
fulfill  that  role,  a  developer  must  adhere  to  a  few  basic 
principles.  Armed  with  this  common  set  of  reference 
principles,  a  developer  is  to  establish  a  communications 
framework  that  embodies  his  particular  data  transfer 
mechanism.  This  section  provides  guidance  in  employing 
Modelman  for  such  purposes. 


3.1  MANDATED  FEATURES 

% 

The  concept  and  generic  description  of  the  five 
layers  of  the  Modelman  Communications  Reference  Model  is 
essential  for  comparison  purposes  and  must  be  maintained  in 
the  order  given.  To  aid  the  developer,  Appendix  B  is 
provided,  which  covers  representative  functions  found  at 
each  of  the  Modelman  Layers  for  a  bus  implementation.  For 
purposes  of  illustration,  a  variety  of  implementation 
examples  are  given  in  Appendix  F. 


3.2  SUBLAYERING  PRIVILEGES 

Where  suitable  classes  of  functions  are  clustered 
together,  a  developer  may  elect  to  define  sublayers  unique 
to  his  data  transfer  mechanism,  provided  that  he  fully 
defines  the  functions  and  interfaces  and  protocols  of  each 
sublayer.  An  example  of  sublayering  is  found  in  the 
Communications  Services  Layer  example  given  in  Appendix  e . 


3.3  TERMINOLOGY 

Where  a  definition  has  been  provided  in  the  main 
body  of  this  document,  the  developer  will  employ  that  term 
rather  than  construct  a  new  one. 


3.4 


STRAWMAN  COMMUNICATIONS  FRAMEWORK 


Those  charged  with  developing  a  strawman  data 
transfer  mechanism  approach  will  develop  a  cormiunications 
framework  of  their  strawman  using  the  terminology  and 
organizing  principles  found  in  Modelman.  The  interfaces 
between  each  layer,  the  protocols  of  each  layer,  and  the 
functions  embodied  within  each  layer  will  be  described.  The 
communications  framework  will  also  describe  the  hardware 
implementation  schemes  realizable  with  the  strawman  data 
transfer  mechanism.  Appendix  f  provides  illustrations  of  a 
variety  of  hardware/software  mappings  into  the  5-layered 
Modelman. 


APPENDIX  E 


MODELMAN  REPRESENTATIVE  FUNCTIONS  BY  LAYER 


This  appendix  describes  a  representative  communications  framework  for 
a  data-transfer  network  in  accordance  with  the  Modelman  Reference  Model. 

It  expands  on  the  reference  model  by  defining  characteristic  features  and 
functions  for  each  layer. 


MODELMAN  REPRESENTATIVE  FUNCTIONS  BY 


1.  GENERAL  LAYER  CHARACTERISTICS 

The  following  list  of  general  layer  features 
serves  to  establish  the  nature  of  the  Modelman  layers  for  a 
bus  implementation .  This  compilation  of  functions 
illustrates  the  method  by  which  the  Modelman  Reference  Model 
can  be  applied  to  form  the  foundation  of  a  communications 
framework . 


The  layers  are  discussed  from  highest  (User)  to 
lowest  (Physical)  in  this  Appendix.  In  two  of  the  layers, 
sublevels  have  been  defined.  The  Communication  Services 
layer  is  composed  of  a  Handler  sublevel,  which  performs 
format  translations  and  ensures  transparency  of  data 
transfer,  and  a  Conveyor  sublevel,  which  manages  the 
end-to-end  transfer  of  data.  The  Conversation  Services 
Layer  is  also  composed  of  two  sublevels:  a  Subscriber 
Selection  sublevel  contains  functions  necessary  to  effect 
physical  data  transfer  when  there  is  a  point-to-point 
interface  between  the  subscriber  and  the  terminal;  and  a 
Conversation  Control  sublevel  negotiates  and  maintains 
conversations  and  performs  necessary  "housekeeping" . 

For  clarity,  a  data  block  will  be  defined  as  the 
unit  transmitted  by  Bus  Network  Control;  the  message  block, 
by  Conversation  Services;  the  message  by  Communication 
Services;  and  the  buffer,  by  User.  A  bus  controller  will 
be  defined  as  a  unit  which  performs  control  and  monitoring 
functions  over  the  bus  medium;  it  may  or  may  not  be  the 
unit  which  is  transmitting. 


1.1  USER  LAYER 

Runtime  Task  Modules 
Subscriber  Services  Modules 
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COMMUNICATION  SERVICES  LAYER 


1  Handler  Sub-Level 
User  Calls 

Software  to  Support  Circuit  Types 
Format  Conversions 
Quality-of-Service  Definition 
Miscellaneous  User  Support  Services 

2  Conveyor  Service  Sub-Level 
Segmenting  of  Data  Buffers 
Address  Assignment 
Flow  Control 

Message  Routing  (to  User) 
Quality-of-Service  Requests 
Message  Timeout 
Sequencing 

Retransmission  Request  Handling 


CONVERSATION  SERVICES  LAYER 


L  Subscriber  Selection  Sub-Level 

Handshake  Control  Logic  &  Interface  Protocols 
Multiplex  Functions 

1.3.2  Conversation  Control  Sub-Level 

Connection  Management 
Negotiation 
Maintenance 

Notification  of  Resource  Unavailability 
Notification  of  Compliance/Non-compliance 
Release 
Addressing 
Priority 

Conversation  Level  Error  Handling 
Message  Block  Sequencing 

Message  Block  Handshake/Validation/Re transmission 

1.4  BUS/NETWORK  CONTROL  LAYER 

Bus  Control 

Bus  Access  Method 
Bus  Allocation 
Bus  Test/Reconfiguration 
Bus  Monitoring 
Priority 
Error  Checking 
Addressing 

Encoding/Decoding 
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Data  Block  Sequencing 

Handshake 

Word 

Data  Block 

Data  Block  Transmission  Timing 

1.5  PHYSICAL  LAYER 

Electrical  Characteristics 
Signal  Levels 

Clock  Rate 

% 

Modulation  Scheme 
Physical  Characteristics 
Medium 

Distances  between  nodes 
Method  of  bus  interface 
Bus  topology 

Other 

Number  of  Users 
Number  of  Channels 
Throughput 

Bit  Level  Error  Checks 
Timing 

Cable  &  Connector  Characteristics 
Nuclear  Survivability 
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DESCRIPTION  OF  LAYER  FUNCTIONS 


FUNCTIONS  COMMON  TO  PROTOCOL  LAYERS 

This  section  mentions  functions  which  could 
conceivably  be  appropriate  in  any  or  all  layers. 


2.1.1  Sequencing 

Each  layer,  with  the  exception  of  the  Physical 
Layer,  is  required  to  provide  some  mechanism  to  ensure  the 
transfer  of  data  units  in  the  proper  order.  This  mechanism 
could  be  in  the  form  of  a  data  unit  sequence  number 
maintained  by  both  the  sender  &  receiver  of  data  units,  a 
message  type  indicator,  a  "more  data"  indicator,  etc. 


2.1.2  Segmentinq/Blocking 

Each  layer  should,  upon  receipt  of  a  data  unit 
from  the  next  higher  (lower)  layer,  segment  (block)  the  unit 
into  its  own  required  data  unit  size.  This  is  due  to  the 
fact  that  no  layer  should  be  required  to  adhere  to  protocols 
in  other  layers,  or  perform  functions  specific  to  protocols 
in  other  layers. 


2.1.3  Error  Checks/Notification/ Recovery 

Each  layer  will  be  responsible  for  monitoring  the 
transmitted  data  for  potential  errors  which  are  peculiar  to 
that  layer.  A  detected  error  may  require  notification  of 
the  higher  layer (s)  for  the  purpose  of  initiating  high  level 
recovery  functions .  Or  recovery  operations  might  be 
performed  by  the  layer  which  detected  the  error. 


2.1.4  Timing/ Timeout 

Timing  functions  may  be  performed  by  any  or  all 
layers  of  Modelman. 


2.2  USER  LAYER 


2.2.1  Runtime  Task  Module 

This  user  level  module  performs  a  tactical 
function  in  real  time  (also  called  a  tactical  application 
computer  task).  These  modules  communicate,  in  general,  with 
other  task  modules  rather  than  peripheral  units  external  to 
the  bus  system. 


2.2.2  Subscriber  Services  Module 

Subscriber  Services  Modules  provide  communication 
control  services  to  external  computers  and  peripherals  which 
do  not  have  a  direct  connection  to  the  bus.  These  modules 
operate  under  the  control  of  the  bus-user  computer ' s 
operating  system.  Subscriber  Services  are  analogous  to  the 
functions  of  Subscriber  Selection  (Conversation  layer)  in 
that  they  often  manage  point-to-point  interfaces  and 
associated  protocols . 


2.3  COMMUNICATION  SERVICES  LAYER 


2.3.1 


Handler 


2. 3.1.1  User  Calls 


The  Handler  sublevel  responds  to  calls  from  users 
desiring  access  to  bus  services.  Among  the  calls  which  may 
be  made  to  Handler  are: 

o  OPEN  connection 

o  CLOSE  connection 

o  LISTEN 

o  SEND  data 

o  RECEIVE  data 

o  REQUEST 

O  RESPOND 


2. 3.1.2  ^  Software  to  support  Circuit  Types 

Handler  must  support  the  circuit  type  requested  or 
required  by  the  User  layer.  That  is,  this  sublevel  may  need 
to  distinguish  between  messages  which  require  replies  and 
those  for  which  replies  are  inappropriate.  Illustrative 
examples  follow: 

o  Handler  must  be  prepared  for  request/ response 
communication  with  a  virtual  circuit  connection. 

o  Handler  may  be  required  to  determine  which 

multicast  messages  received  require  response  or 
acknowledgement . 


2. 3. 1.3  Format  Conversions 

Since  it  is  Handler  responsibility  to  ensure 
transparency  of  data  transfer,  format  conversion  is  effected 
in  this  sublevel.  Handler  must  translate  user  format  to  the 
form  and  syntax  which  is  used  on  the  bus.  Included  among 
Handler  format  conversions  are: 

o  Translations  of  data  representation  -  single-or 
multiple-byte  numerical  data,  character 
representations  (ASCII,  EBCDIC,  etc.),  coded 
sensor  data,  graphics  control  and  data. 
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o  Message  transfer  types  -  file,  line,  word. 

o  Internetwork  Communication  -  translation  from  one 
network  protocol  to  another,  when  the 
terminal /computer  is  serving  as  an  internetwork 
gateway 


2. 3.1.4  Quality-of-Service  Definition 

A  user  task  will  require  a  particular  quality  of 
service  depending  on  task  priority,  the  nature  of  the  source 
and  destination,  and  system  environment  status  (combat  or 
non-combat  situation),  among  others.  Handler  will  define 
the  necessary  quality  of  service  relative  to  these  factors 
and  will  instruct  the  Conveyor  to  implement  or  request  this 
service . 


2. 3. 1.5  Miscellaneous  User  Support  Services 

Handler  should  provide  various  services  which 
prepare  the  users  for  data  transfer  and  which  establish  the 
rules  of  the  conversation.  Included  among  user  support 
services  are: 

o  synchronization  of  communicating  processes 
o  agreement  on  a  privacy  mechanism 
o  assessment  and  distribution  of  costs 


2. 3. 1.6  Conveyor 


2. 3.2.1  Segmenting  of  Data  Buffers 

The  initial  segmenting  of  user  data  buffers  occurs 
in  the  Conveyor  sublevel.  (The  Handler  sublevel  does  not 
segment  buffers  but  performs  format  translations  and  affixes 
Handler  protocol  fields  to  the  data.)  Refer  to  section  2.1. 

The  Conveyor  sublevel  is  responsible  for 
comnunicating  Conveyor  message  size  to  the  peer 
Communication  Services  layer,  if  this  size  has  not  been 
predefined  for  all  bus  subscribers.  When  receiving  data, 
this  sublevel  must  block  it  into  buffers  depending  on  the 
size  of  messages  being  received. 
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2. 3. 2. 2  Address  Assignment 


Conveyor  assigns  names  (addresses)  to  user 
processes  for  use  by  itself  and  the  layers  below  it.  This 
would  entail  maintaining  a  list  of  permanent  names  for 
sources  and  destinations  or  assigning  new  addresses  for  each 
connection.  Conveyor  is  also  responsible  for  communicating 
these  addresses ,  as  necessary,  to  peer  Conmunication 
Services  layers. 


2. 3.2. 3  Flow  Control 

Functions  in  this  category  of  the  Conveyor 
sublevel  may  operate  in  conjunction  with  routing  and 
segmenting  functions  in  that  the  rate  of  data  transfer 
between  users  could  be  a  function  of  the  amount  of  buffer 
space  available  to  a  single  user  and  the  size  of  the 
messages  being  transferred.  Through  Communications  Services 
peer  protocol,  the  receiving  Conveyor  level  may  be  able  to 
meter  the  rate  at  which  the  sender  transmits  data. 


2. 3.2.4  Message  Routing  (to  User) 

Routing  of  data  buffers  from  the  bus  to  the  user 
is  performed  in  Communication  Services.  These  routing 
functions  occupy  the  Conveyor  Sublevel  since  Conveyor 
ensures  that  all  buffers  formed  at  higher  layers  are  dent 
and  received  via  Conversation  level  connections. 


2. 3. 2. 5  Quality-of-Service  Requests 

The  quality’  of  service  (response  time,  error  rate, 
etc . )  that  is  required  by  a  particular  user  is  defined  in 
Handler .  Conveyor  is  responsible  for  interpreting  the 
defined  service  requirements  and  making  requests  to  the 
Conversation  layer  to  negotiate  a  connection  Which  will 
provide  the  necessary  service. 


2. 3. 2. 6  Message  Timeout. 

See  Section  2.1 


2. 3.2.7  Sequencing 

See  Section  2 . 1 

2. 3.2.8  Retransmission  Request  Handling 

Communication  Services  handles  end-to-end 
retransmission  requests,  through  Conveyor  peer  protocol, 
prior  to  data  buffers'  being  passed  to  the  User  layer. 


2.4  CONVERSATION  SERVICES  LAYER 


2.4.1  Subscriber  Selection 


2. 4. 1.1  Handshake  Control  Logic  &  Interface  Protocols 

This  sublevel  provides  for  the  necessary  protocols 
and  handshake  frames  or  signals  which  are  required  by  the 
particular  point-to-point  inter face( s) ,  including  proper 
timing  and  signal  levels.  For  example.  Subscriber  Selection 
will  handle,  among  others: 

o  ODR/ODA,  IDR/IDA,  etc.,  for  MIL-STD-1397 

o  SIS,  SOS  control  frames  for  STANAG  4153 
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2 . 4 . 1 . 2  Multiplexing 

Subscriber  Selection-level  multiplexing  concerns 
the  case  in  which  multiple  hosts  (computing  elements  which 
contain  the  User  and  Communication  Services  layers)  must  be 
serviced  over  a  switched  point-to-point  link.  Subscriber 
Selection  must  notify  Conversation  Control  as  to  which  host 
(user)  is  transferring  data. 


2.4.2  Conversation  Control 


2. 4. 2.1  Connection  Management 

The  purpose  of  connection  management  is  to 
establish  and  maintain'  data  communication  (connections) 
between  bus  users.  Among  the  functions  encompassed  by 
Connection  management  are  connection  negotiation,  connection 
maintenance,  notification  of  compliance/non-compliance, 
notification  of  resource  unavailability,  and  connection 
release . 


2. 4. 2. l.l  Connection  Negotiation 

During  the  negotiation  phase,  the  Conversation 
Layer  must  initialize  the  parameters  pertinent  to  the  "new 
conversation.  These  include  source/ destination  addresses, 
service  type  &  class  required,  circuit  type  (virtual 
circuit,  datagram,  etc.)  &  message  sequence  indicator,  among 
others.  The  Conversation  Layer  must  also  notify  its  peer 
Conversation  Layer  of  parameters  which  must  be  used  or 
included  in  data  units  exchanged  on  the  new  connection. 


2. 4. 2. 1.2  Connection  Maintenance 

A  record  must  be  maintained,  in  the  Conversation 
Layer,  of  parameters  pertinent  to  all  current  conversations. 
In  addition,  the  layer  must  be  able  to  accommodate  any 
desired  or  necessary  changes  of  the  parameters  on  request 
frcm  a  peer  Conversation  Layer  or  from  its  own  next  higher 
layer . 
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2. 4. 2. 1.3  Notification  of  Compliance/Non-compliance 

Conversation  Services  protocol  may  require  that 
this  layer  notify  a  peer  Conversation  Layer  as  to  its 
ability  to  honor  a  request  for  a  certain  service  or 
connection  type.  This  notification  could  occur  during 
either  connection  negotiation  or  maintenance  phase. 


2. 4. 2. 1.4  Notification  of  Resource  Unavailability 

During  the  course  of  a  conversation  (either 
negotiation  or  maintenance  phase),  a  host  resource  may 
became  unavailable  for  service  to  bus  users.  In  this  case, 
the  Conversation  Layer  is  responsible  for  notifying  peer 
Conversation  Layers,  desiring  or  holding  conversations  with 
the  host  resource,  of  its  unavailablility. 


2 . 4 . 2 . l .  5  Connection  Re lease 

The  Conversation  Layer  must  provide  for  the 
orderly  termination  of  a  connection  without  loss  of  data 
When  possible,  on  request  from  an  upper  layer  or  a  peer 
Conversation  Layer.  Connection  release  may  precede  the 
renegotiation  of  conversation  parameters. 

An  emergency  release  or  abort  would  be  provided 
for  at  this  layer.  Abort  would  releas"  the  connection  but 
not  necessarily  prevent  data  loss  between  users,  and 
notification  of  the  abort  may  be  required. 


2. 4. 2. 2  Addressing 

Translating  logical  or  functional  addresses  into 
physical  addresses  (bit  patterns)  is  a  function  of  the 
Conversation  Services  Layer,  as  is  relating  source  and 
destination  addresses  to  a  particular  connection. 
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2 . 4 . 2 . 3  Priority 


Message  priority  addressed  in  this  layer  concerns 
message  blocks  which  have  been  designated  by  the 
Conversation  Layer  as  having  priority  over  previous  messages 
transmitted  over  the  same  connection. 


2. 4. 2. 4  Error  Checking  And  Handling 

At  the  Conversation  Services  Level  error  checking 

includes : 

Connection  Management  Errors 
Addressing  Errors 
Negotiation  Procedure  Errors 
Message  Block  Format  Errors 
Message  Block  Timing,  Sequencing  Errors 


Message  Block  Sequencing 
See  Section  2 . 1 


J.4.2.6  Message  Block  Handshake/Validat ion/ Retransmission 

This  heading  encompasses  functions  that  support 
virtual  circuit  transmission.  Handshake  could  be 
accomplished  through  ACK/lJAK,  Request/ Response.  Functions 
in  this  category  work  in  conjunction  with  Conversation  Level 
error  checking  for  message  block  validation. 


2.5 


bus/network  control  layer 


Since  operations  performed  by  the  bus  controller 
differ  from  those  performed  by  other  units,  the  functions  in 
the  Bus/Network  Control  Layer  have  been  designated  as 
pertaining  to  the  controller,  the  non-controller,  or  both. 


2.5.1  Bus  Control 

Among  the  functions  encompassed  by  Bus  Control  are 
bus  access  protocol,  bus  allocation,  bus  test  and 
reconfiguration,  and  bus  traffic  monitoring.  The  types  of 
entities  performing  the  functions  can  be  diverse  in  nature.  , 
For  example,  bus  monitoring  and  test  may  be  performed  by  a 
different  unit  than  that  which  is  performing  other  bus 
control  functions;  or  the  same  unit  might  be  responsible 
for  all  functions. 

Likewise,  the  controller  functions  might  be 
distributed  among  elements  on  the  bus  or  be  handled  by  an 
individual  control  unit.  In  the  latter  case,  the  controller 
could  be  a  dedicated  unit,  a  bus-service  subscriber  which  is 
acting  as  controller  (temporary  or  permanent),  or  a 
combination  of  the  two. 

Each  Bus/Network  Control  function  will  be 
addressed  individually. 


2.5. l.i  Bus  Access  (Controller/Non-controller) 

Each  bus  access  method,  though  usually  associated 
with  one  type  of  control  scheme,  can  be  used  in  systems  with 
distributed  controllers,  individual  controllers,  or 
combinations  of  these. 


o  Contention  -  distributed  controller 

In  Carrier  Sense  Multiple  Access  with  Collision 
Detection  (CSMA/CD)  control  of  bus  access  and  the 
accompanying  back-off  schemes  are  usually 
distributed  among  all  units 

o  Contention  -  individual  controller 

A  bus  monitor  could  alter  collision  back-off 
interval  of  non-controller  units  during  periods 
of  heavy  bus  traffic 


! 


o  Token  -  individual  controller 

Total  bus  control,  in  the  case  of  dynamic  bus 
allocation,  can  be  offered  (in  the  form  of  a 
token)  to  another  unit  by  the  present  bus 
controller . 

o  Token  -  distributed  master 

With  all  units  sharing  control,  right-to-transmit 
might  be  passed  for  only  a  single  transmission 


2. 5. 1.2  Bus  Allocation  (Controller) 

This  heading  encompasses  such  functions  as 
permission-to-transmit  request/grant,  and  "turns".  Turns 
could  be  an  explicit  function  of  a  dedicated  or  individual 
controller,  or  an  implicit  function  in  the  case  of  a 
distributed  controller. 

Illustrative  examples  of  bus  allocation  include: 

o  permission-to-transmit  granted,  via  control 
words,  to  a  single  unit  by  the  bus  controller. 

o  right  to  transmit  may  be  granted  in  the  case  of  a 
ring-type  bus,  to  the  immediately  subsequent 
unit. 

o  right  to  transmit  may  be  passed  to  a  single  unit 
whose  identity  has  been  previously  defined. 

o  length  of  the  back -off  interval  (in  CSMA/CD) 
might  determine  the  amount  of  bus  service 
allocated  to  a  particular  unit. 


2.5.1. 3  Bus  Test/ Reconfiguration  (Controller) 

Bus  test  will  include  tests  of  the  medium, 
terminal  units  &  the  controller  (self-test).  In  addition, 
diagnostics  for  subscriber  use  &  test  of  the  subscriber 
system  may  fall  into  this  category.  Bus  test  can  be  active 
(eg.  polling  terminal  units  for  status)  or  passive  (eg. 
monitoring  selected  bus  transmissions  -  this  could  work  in 
conjunction  with  Bus  Traffic  Monitoring) . 

The  Reconfiguration  function  includes  switch  to 
backup  systems,  rerouting  around  a  failed  element,  and 
remedial  action  (eg.  terminal  reset). 


2. 5. 1.4  Bus  Traffic  Monitoring  (Controller) 


This  category  includes  moni*- 'ting  the  volume  of 
traffic  on  the  bus  as  a  Whole,  or  front  an  individual 
terminal,  to  detect  bottlenecks  and  other  traffic 
irregularities.  Functions  at  this  level  ensure  that  no 
terminal  monopolizes  the  bus;  this  could  be  accomplished 
through  affecting  the  back-off  scheme  in  CSMA/CD  or 
disabling  the  terminal,  among  others.  Rerouting  of  traffic 
is  also  performed  around  bottlenecks. 

Note  that  functions  in  this  category  overlap  or 
work  in  conjunction  with  functions  considered  as  Bus 
Test/ Reconfiguration . 


2.5.2  Priority  (Controller  and/or  Non-controller) 

Two  types  of  priority  are  addressed  by  the 
Bus/Network  Control  Layer:  subscriber  priority  and  message 
priority. 


2 . 5 . 2 . 1  Subscriber  Priority 

Certain  terminals  or  subscribers  may  be  polled 
more  frequently  by  the  controller  than  others,  or,  in  the 
case  of  contention-type  access,  may  back-off  for  a  shorter 
interval  than  other  units. 


2. 5. 2. 2  Message  Priority 

Certain  messages  may  be  given  higher  priority  than 
others  when  being  placed  on  the  bus,  for  example  command  and 
control  messages.  (The  Conservation  Layer  also  addresses 
priority) . 
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2.5.3  Error  Checking  and  Handling 
( Control ler/ Non-con trol 1 er ) 

Mote:  Each  layer  will  have  error  handlers  pertinent  to  its  own 
functions . 

At  the  Bus/Uetwork  Control  Level  error  checking 

includes : 


Word  Length 
Data  Block  Length 
Data  Block  Format 
Word  Format 
Bus  Allocation 
Timing 
Frame  Checks 


2.5.4  Addressing  (Controller /Non-controller) 

The  encoding  and  decoding  of  address  fields  in 
message  blocks  are  effected  in  the  Bus  Network  Control 
Layer.  This  does  not  include  translation  of  logical 
addresses  to  physical  addresses  (bit,  patterns),  which  will 
be  handled  by  the  Conversation  Services  Layer. 


2.5.5  Data  Block  Sequencing  (Controller/Non-controller) 
See  Section  2 . 1 

2.5.6  Handshake 

Handshake  functions  either  overlap  or  work  in 
conjunction  with  Error  Checking  functions. 
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2. 5. 6.1  word  Handshake  ( Controller /Non-cont rol ler 5 


This  category  encompasses  such  functions  as  parity 
checks,  word  format  checks,  ACK/lIAK  of  invalid  words,  and 
interpretation  of  Ready- to- Send,  Ready-to-Receive  signals. 


2. 5. 6. 2  Data  Block  Handshake  (Controller/Non-controller) 

Data  block  handshake  functions  include  CRC  checks, 
format  checks  and  ACK/NAK  of  invalid  data  blocks.  In 
addition,  certain  sequencing  functions  would  be  performed  at 
this  level.  For  example,  if  the  particular  message  just 
received  must  be  followed  by  another  message  of  a  specified 
type,  receipt  of  a  message  of  invalid  type  could  indicate  a 
sequencing  error. 


2.5.7  Data  Block  Transmission  Timing 
l Controller 7Non-cont ro 1 1 er) 

Functions  in  the  Bus/Network  Control  Layer 
measure/generate  intermessage  time  intervals  and 
intramessage  intervals  (eg.  time  between  the  transmission 
of  the  "RECEIVE"  command  (from  the  controller)  and  the 
transmitted  data).  The  bus  access  timing  mechanisms  reside 
in  this  layer. 


2.5.8  Additional  Bus/Network  Control  Functions 

The  Bus/Network  Control  Layer  must  provide  the 
requested  quality  of  Service  to  the  Conversation  Layer  i.e. 
normal  or  expedited  data  transfer,  required  error  rate,  etc. 
This  service  must  be  provided  in  the  most  cost-effective 
manner,  and  the  Bus/Network  Control  must  therefore  perform 
such  functions  as  routing  to  minimise  access  delay,  and  maximize 
throughput . 


APPENDIX  F 


MODELMAN  HARDWARE  IMPLEMENTATION  EXAMPLES 


This  appendix  presents  examples  of  hardware  implementation  for  a  data- 
transfer  network  that  conforms  to  the  Modelman  Reference  Model. 
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MODELMAN  HARDWARE  IMPLEMENTATION  EXAMPLES 


The  Modelman  Reference  Model  has  been  consciously- 
defined  to  permit  three  different  terminal  implementations: 
Bnbedded  Case,  External  Terminal  Case,  and  Enhanced  External 
Terminal  Case.  Specific  Strawman  approaches  may  address  any 
or  all  of  these  cases. 


1.1  IMBEDDED  CASE 

This  configuration  concerns  a  bus  subscriber  which 
contains  all  data  bus  hardware,  and  the  software  to  control 
it,  within  itself  (See  Figure  F-l) .  All  Modelman  layers 
reside  in  the  subscriber  computer. 


1-2  EXTERNAL  TERMINAL  CASE 

This  implementation  concerns  a  case  in  Which  the 
terminal  (hardware  and  software  pertinent  to  data  bus 
operation)  is  physically  separate  from  the  bus  subscriber 
(See  Figure  f-2)  .  Here,  the  subscriber's  operating  system 
requires  modification  to  permit  control  of  and  communication 
with  the  External  Terminal. 

In  this  configuration,  there  is  a  physical 
point-to-point  interface  between  the  subscriber  and  the 
terminal.  Further,  there  is  a  possibility  of  multiple 
subscriber  computing  elements  gaining  bus  access  through  a 
single  terminal;  this  could  require  a  switched 
point-to-point  link.  The  switching  control  would  reside  in 
Conversation  Services.  External  Terminal  subscribers  will 
generally  be  computers;  it  is  anticipated  that  few 
present-day  peripherals  will  be  capable  of  performing  the 
higher  layer  functions  necessary  in  External  Terminal 
Configurations . 

If  the  subscriber  computing  element  connects  and 
provides  comnunication  features  to  an  external  element  (via 
direct  or  switched  point-to-point),  the  point-to-point 
interface  control  will  typically  be  a  function  of  the 
computing  element’s  operating  system  or  executive. 
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IMPLEMENT  A  TION  EXAMPLES 


IMPLEMENT  A  TION  EXAMPLES  figure  f-2 
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ENHANCED  EXTERNAL  TERMINAL  CASE 


The  Enhanced  External  Terminal  (Figure  f-3)  can  be 
considered  a  highly  intelligent  "black  box"  which  is  capable 
of  performing  all  data  bus  operations.  It  is  tailored  to 
the  case  where  only  minimal  software  modifications,  and  no 
hardware  modifications  can  be  made  to  the  subscriber .  All 
Modelman  layers  are  implemented  in  the  Enhanced  External 
Terminal . 


The  terminal  can  provide  bus  services  to  many 
subscribers,  including  computers  and  smart  and  dumb 
peripherals,  via  direct  or  switched  point-to-point 
interfaces.  Control  of  these  interfaces  resides  in  the 
Enhanced  Terminal's  User  layer  (Subscriber  Service  Modules). 
Multiple  interfaces  of  various  types  (NTDS,  STANAG  4153, 
etcr)  can  be  accommodated  simultaneously  by  the  Enhanced 
Terminal . 

Note  that  the  subscriber  computer,  in  this  case, 
will  be  executing  User-level  Runtime  Task  Modules. 


1.4  ADDITIONAL  IMPLEMENTATIONS 

The  Modelman  Reference  Model,  while  addressing 
data  transfer  mechanisms,  does  not  imply  that  layering 
principles  are  inappropriate  for  direct  connections.  With 
seme  modifications,  Modelman  can  be  applied  to  both  direct 
and  switched  point-to-point  connections  and  intracomputer 
communication  as  well. 

In  such  instances,  communication  between  users 
requires  only  selected  services  of  lower  protocol  layers  of 
this  Reference  Model.  In  the  case  of  intracomputer 
communication  (where  user  processes  reside  in  the  same 
computer) ,  the  management  of  conversations  is  required  by 
the  higher  layers,  although  no  physical  interface  between 
users  exists  (Figure  F-4)  .  In  the  case  of  point-to-point 
(where  a  direct  connection  between  computers  precludes  or 
eliminates  the  need  for  bus  medium  access),  the  physical 
control  and  data  block  transfer  control  functions  are 
required  although  they  pertain  to  the  point-to-point 
connection  rather  than  to  a  bus  (Figures  f-5,f-6). 

To  accommodate  these  selected  services  a  two-layer 
Bus  Emulation  Service  construct  has  been  added.  Bus 
Bnulation  Service  performs  functions  analogous  to  those 
located  in  the  Conversation  Services  and  Bus  Network  Control 
Layers.  It  therefore  presents  to  the  upper  layers  the 
appearance  of  connection  to  a  bus  network,  and  it  provides 
services  necessary  for  the  maintenance  of  conversations  and 
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IMPLEMENTATION  EXAMPLE 

POINT-TO-POINT  figure  f-6 

MODELMAN  (SWITCHED  LINKS ) 

REFERENCE  MODEL  COMPUTER  COMPUTER  TRANSFER/ 

LAYERS  OR  PERIPHERAL  COMPUTER  OR  PERIPHERAL  EXECUTION  SPEED 
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the  orderly  transfer  of  data.  Ideally,  the  Communication 
Services  Layer  should  not  be  able  to  distinguish  between  the 
services  provided  by  Conversation  and  those  provided  by  Bus 
Emulation . 


1.5  IMPLEMENTATION  SUMMARY 

Figures  P-7  and  F-8  summarize  the  previously 
described  hardware  implementation  examples  of  the  Reference 
Model.  These  figures  indicate  the  location  in  hardware  of 
each  of  the  Modelman  layers .  Also  indicated  is  the  flow  of 
data,  as  well  as  control  over  data,  through  each  layer  and 
sublayer  defined  in  Appendix  E. 
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IMPLEMENTATION  EXAMPLES 


IMPLEMENTATION  EXAMPLES  (CO NT.) 


HARDWARE  IN  WHICH  FUNCTIONS  RESIDE  2  777X  INDICATES  LAYER  OR  SUBLEVEL  IS  NULL  IN  THIS  CASE 


APPENDIX  G 


TECHNICAL  COMMENTS  ON  THE  SITACS  PLAN 


This  appendix  is  a  consolidation  of  the  technical  comments  obtained 
from  a  review  of  the  SEA-61  SITACS  proposal  by  members  of  the  DBSWG. 

The  purpose  of  the  SITACS  plan  was  to  stress  compatibility  with  exist¬ 
ing  designs  and  independence  from  combat  system  architectures  as  primary 
goals.  However,  emphasis  is  solely  on  a  fixed  architecture  of  Low-Level 
Serial  (LLS)  interfaces  with  LLS  switching,  thus  excluding  at  the  outset 
all  other  possible  approaches.  The  objective  of  being  maximally  compatible 
with  STANAG  4153,  together  with  not  addressing  any  NTDS  interface  require¬ 
ments,  appears  to  ignore  the  most  likely  situation  that  NTDS  parallel  inter¬ 
faces  will  still  be  in  active  use  for  several  more  decades  and  will  need  to 
be  connected  into  a  SITACS  system.  This  approach  precludes  the  consideration 
of  fiber  optics. 

The  plan  appears  to  say  that  a  single  bus  is  required  for  the  total 
combat  system.  The  architecture  of  a  bus  system  should  not  be  fixed  as 
implied  by  the  plan.  The  need  is  to  define  a  single  type  or  limited  number 
of  types  of  bus  for  use  as  parts  of  the  combat  system  data  network,  which 
must  be  amenable  to  tailoring  by  the  combat  system  engineers  to  the  desired 
combat  system  architecture  for  each  specific  application.  The  goal  of  the 
DBSWG  is  to  provide  a  new  tool  that  will  permit  the  DDGX  "ombat  System 
Engineering  Agent  (CSEA)  or  element  designer  to  obtain  better  life-cycle 
cost,  survivability,  and  availability  by  using  improved  technology  than 
can  be  obtained  by  relying  solely  on  traditional  point-to-point  wiring. 

It  is  up  to  t.ie  element  designer  and  combat  system  integrator  to 
design  the  data  network.  This  should  be  done  by  using  the  most  appropriate 
combination  of  techniques.  In  the  DDGX,  this  combination  will  undoubtedly 
include  data  buses,  STANAG  4153,  switches,  and  MIL- STD-1397  interfaces,  as 
well  as  appropriate  operating  system  and  application  program  constructs. 

In  addition,  the  data  bus  standard  (MIL-STD-1553B)  currently  in  use  in 
avionic  systems  cannot  be  ignored.  Experience  gained  from  the  use  of  that 
bus  should  be  applied  to  ship  combat  systems.  One  possibility,  using  MIL- 
STD-1553B,  is  the  replication  of  buses  to  provide  the  required  bandwidth. 

A  bus  system  is  not  intended  to  be  a  transparent  replacement  for  point-to- 
point  wiring.  Thus  a  trade-off  in  capabilities  is  expected.  To  require 
transparency  would  vitiate  taking  full  advantage  of  a  data  bus. 
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The  existing  efforts  in  the  commercial  sector  (e.g.,  ISO  reference 
model,  IEEE  local  network  standards  efforts)  have  been  ignored.  A  method 
for  involving  Na’^y  acquisicion  managers  and  Navy-oriented  industry  is  miss¬ 
ing.  Such  involvement  is  critical  to  the  usefulness  and  acceptance  of  any 
tactical  communications  specification  or  standard.  The  GFE  approach  is  not 
presented  with  any  justification.  It  may  not  even  be  desirable  when  com¬ 
pared  with  the  embedded  CFE  terminal.  The  schedule  as  presented  does  not 
permit  any  genuine  industry  or  user  interaction  in  the  design  of  the  data 
bus,  but  permits  only  a  rubber  stamp  of  the  SEA-61  design.  In  fact,  the 
GFE  approach  specified  for  the  external  terminal  will  probably  not  meet  the 
schedule  required  for  DDGX. 

Without  some  common  reference  mode  (e.g.,  ISO  model)  and  all  of  its 
attendant  definition,  it  is  difficult  to  understand  the  SITACS  plan  (e.g., 
terms  like  "trunk"  protocol).  Typically,  there  are  "protocols"  and  there 
are  "interfaces."  Phrases  like  "interface  protocols"  require  definition. 

The  plan  seems  to  be  an  argument  against  the  use  of  a  data  bus  rather  than 
a  plan  for  developing  a  data  bus  specification.  On  the  basis  of  the  limited 
technical  details  on  SITACS  presented,  it  appears  to  require  a  lot  more 
cable  than  a  bus,  because  of  its  switching  nodes.  It  does  not  seem  to  allow 
"receive  selection"  philosophy. 

A  combat  system  element  is  a  collection  of  devices.  These  may  include 
sensors,  computers,  and  controlled  devices.  It  is  unclear  whether  the 
SITACS  network  is  to  be  used  inside  or  between  elements.  Does  it  include 
internal  data  paths  within  a  computer?  The  plan  proposes  a  "standard 
information-transfer  system  architecture, "  which  implies  the  basic  design 
of  all  information  transfer  within  the  combat  system,  including  voice,  very- 
high-bandwidth  radar  data,  and  intercomputer  data.  However,  the  plan  limits 
itself  to  intercomputer  and  other  digital  data  transfer  only. 

The  NAVSEA  06D  plan  does  not  a  priori  restrict  itself  to  one  architec¬ 
ture,  but  may  evolve  to  a  particular  architecture,  perhaps  even  SITACS. 

The  intent  of  the  NAVSEA  06D  plan  is  to  supply  a  tool  that  can  be  used  with 
other  tools  (e.g.,  STANAG  4153,  MIL-STD-1553B,  IVCS,  SDMS,  MIL-STD-1397 
Type  A)  by  the  Combat  System  Engineering  Agent  (CSEA)  and  other  system 
designers  to  develop  the  DDGX  information  network. 
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APPENDIX  H 


FIRMS  SUBMITTING  LETTERS  OF  INTEREST  IN  DATA 
BUS  PRODUCIBILITY  STUDIES 


This  appendix  lists  the  41  firms  responding  to  an  announcement  in  the 
Commerce  Business  Daily  on  11  December  1980  notifying  industry  of  the  Navy's 
intention  to  perform  data  bus  producibility  studies. 
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FIRMS  SUBMITTING  LETTERS  OF  INTEREST  IN 
DATA  BUS  PRODUCIBILITY  STUDIES 


Advanced  Computer  Techniques  Corporation 
437  Madison  Avenue 
New  York,  New  York  10022 
Attn:  George  Finckenor 

Advanced  Technology,  Inc. 

7923  Jones  Branch  Drive 
Suite  500 
McLean,  VA  22102 
Attn:  Raymond  W.  Hine 

American  Computer  and  Electronics  Corp. 
Two  Professional  Drive 
Suite  242 

Gaithersburg,  MD  20760 
Attn:  Kim  E.  Richeson 

Applied  Technology 
A  Division  of  Itek  Corporation 
1901  N.  Moore  Street 
Suite  908 

Arlington,  VA  22209 
Attn:  James  M.  Finley 

Bolt  Beranek  and  Newman  Inc. 

50  Moulton  Street 

Cambridge,  MA  02138 

Attn:  Joseph  B.  Walters,  Jr. 

Computer  Sciences  Corporation 
Defense  Systems  Division 
304  West  Route  38,  Box  N 
Moorestown,  NJ  08057 
Attn:  Carl  J.  Vesper 

Data  Systems  Analysts,  Inc. 

10400  Eaton  Place 
Suite  201 

Fairfax,  VA  22030 
Attn:  Robert  J.  Cunius 


EG&G  Washington  Analytical  Services 
Center ,  Inc . 

2150  Fields  Road 
Rockville,  MD  20850 
Attn:  George  L.  Bill 

E-Systems,  Inc. 

Melpar  Division 
7700  Arlington  Boulevard 
Falls  Church,  VA  22046 
Attn:  Mr.  C.  C.  Fritsche 
(Code  E5/CD-6805) 

Effects  Technology,  Inc. 

A  Subsidiary  of  Flow  General  Inc. 
5383  Hollister  Avenue 
Santa  Barbara,  CA  93111 
Attn:  Carole  A.  Bryant 

FMC  Corporation 
Northern  Ordnance  Division 
4800  East  River  Road 
Minneapolis,  MN  55421 
Attn:  Larry  A.  Meyer 

W.  w.  Gaertner 
205  Saddle  Hill  Road 
Stamford,  CN  06903 
Attn:  Dr.  W.  w.  Gaertner 

General  Electric  Company 

Electronics  Laboratory 

P.O.  Box  4840 

Syracuse,  NY  13221 

Attn:  Eldon  D.  Fox  (EP  3-103) 

General  Research  Corporation 
Southern  Division 
307  Wynn  Drive 
Huntsville,  AL  35805 
Attn:  Dr.  Glenn  Cox 


Georgia  Tech  Research  Institute 
Code  SS-10106 

Georgia  Institute  of  Technology 
Atlanta,  GA  30332 
Attn:  Donald  J.  Grace 

Grumman  Aerospace  Corporation 
Engineering  Development  Center 
Bethpage,  NY  11714 
Attn:  Christopher  J.  Witt 

HDR  Systems ,  Inc . 

8404  Indian  Hills  Drive 
Omaha,  Nebraska  68114 
Attn:  John  F.  Eagleton 

Harris  Corporation 
Government  Communications  Systems 
Division 
P.O.  Box  37 
Melbourne,  FL  32901 
Attn:  R.  H.  Painter 

JMS  Corporation 
15912  Shady  Grove  Road 
Gaithersburg,  MD  20760 
Attn:  Jeffry  Yeh 

International  Business  Machines 
Corporation 

Federal  Systems  Division 
Route  17C  Tioga  County 
Owego,  NY  13827 
Attn:  Frank  J.  Romanelli 

International  Computing  Company 
4330  East-West  Highway 
Bethesda,  Maryland  20014 
Attn :  John  Kenyon 

International  Telephone  and  Telegraph 
Corporation 

Defense  Communications  Division 
Telecommunications  and  Electronics 
Group-North  America 
492  River  Road 
Nutley,  NJ  07110 
Attn:  Murray  Weinberg 

International  Telephone  and  Telegraph 
Corporation 

Electro-Optical  Products  Division 
7635  Plantation  Road 
Roanoke,  VA  24019 
Attn:  Jack  B.  Freeman 


JRS  Industries,  Inc. 

11722  Sorrento  Valley  Road 
San  Diego,  CA  92121 
Attn:  Erwin  H.  Warshawsky 

Lockheed  Electronics  Company,  Inc. 
U.S.  Highway  22 
Plainfield,  NY  07061 
Attn:  Walt  J.  Lictles 

Magnavox  Data  Systems,  Inc. 

2980  Telestar  Court 
Falls  Church,  VA  22042 
Attn:  Jerry  D.  Elliott 

Network  Analysis  Corporation 
301  Tower  Building 
Vienna,  VA  22180 
Attn:  Patty  Roepken 

Oakwood  Electronic  Systems,  Inc. 
2424  Far  Hills  Avenue 
Dayton,  Ohio  45419 
Attn:  Clifford  W.  Kruer 

RCA  Corporation 

Government  Systems  Division 

Missile  and  Surface  Radar 

Borton  Landing  and  Marine  Highway 

Moorestown,  NJ  08057 

Attn:  Edward  C.  Capone  (M/S  127-3 

Raytheon  Company 
Equipment  Division 
Boston  Post  Road 
Wayland,  MA  01778 
Attn:  Shay  D.  Assad 

Rockwell  International 
Defense  Electronics  Operations 
Autonetics  Marine  Systems  Divisioi 
Shipboard  Information  Systems 
3370  Miraloma  Avenue 
P.O.  Box  4921 
Anaheim,  CA  92803 
Attn:  R.  G.  Titus 

Gordon  S.  Rosen  Assoc.  Inc. 

Pomona  Professional  Plaza 
Route  45 

Pomona,  NY  10970 
Attn:  M.  B.  Fannon 
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MICROCOPY  HI  SOLUTION  Tt  SI  CHARI 


SEMCOR,  Zac. 

2341  Jefferson  Davis  Highway 
Arlington,  VA  22202 
Attns  Lea  Ashman 

Shaker  Research  Corporation 
Northway  10  Executive  Park 
Sallston  Lake,  NY  12019 
Attns  Lawrence  J.  Lagace 

Sperry  Ohivac 

Defense  Systems  Division 

P.O.  Box  3S25 

St.  Paul,  Ml  55165 

Attn:  D.  G.  Schaefer  (M/S  U1J13) 

Teledyne  System  Coapany 
19601  Kordhoff  Street 
Northridge,  CA  91324 
Attn:  Joe  Prase 11 

Telephonies  Corporation 
770  Park  Avenue 
Huntington,  MY  11743 
Attn:  Harris  D.  Graber 

Triad  Microsystems,  Znc. 

555  Sparkman  Drive 
Suite  636 

Huntsville,  AL  35805 
Attn:  Alan  D.  Sharer 

Update  Research  a  Development 
P.O.  Box  831 
Glendora,  CA  91740 
Attn:  Dr.  Don  M.  Yea 

Malden  Management  Services,  Znc. 

A  Subsidiary  of  XMS  Industries,  Inc. 
3980  Quebec  Street 
Denver,  CO  80207 
Attn:  Ron  R.  Brennan 

Mood- Ivey  Systems  Corporation 
3535  Porsyth  Road 
Orlando,  PL  32807 
Attn:  H.  Reese  Ivey 


